I realize that this topic can be considered a bit controversial; but what to do when confronted with the decision on whether or not to install client tools directly onto a BI Platform 4.x server. The recommended practice that you will most commonly hear is to not install the client tools directly on the server but there are some compelling reasons why you may want them there and there are also reasons it might not be a good idea. I will attempt to briefly weigh the pros and cons of doing so.
5 Reasons to avoid installing the client tools directly on the BI Platform Server:
- Developers with access to the server are tempted to do their development directly on the server rather than from their own client system. I won't delve into the myriad of reasons of why this is horrible idea. I'll just leave this to my experience that if people have this access they will use it despite all the advice in the world you give them not to do.
- It will increase the time it takes when you apply patches and support packs. It can take long enough to update your system especially if you have multiple languages installed. Once you do this you will need to update these tools each time you update the server as well.
- It consumes drive space. In many environments infrastructure admins are stingy with space and with good reason. High quality disk can be expensive.
- Software installed on a server may not behave the same way it does on a client system. Servers tend to be secured at a higher level than client systems and as a result some features may not work as expected or at all.
- It may violate separation of duties principles. If you work in a publicly traded company or are otherwise regulated it may open the potential for an administrator to modify reports and other content. Odds are your administrator is completely ethical but expect an auditor to question you and be prepared to prove that content cannot be modified without the proper business authority do so.
5 Reasons to consider installing the client tools directly on the BI Platform Server
- If you are working in an distributed environment where you have configured multiple hosts it can be helpful to ensure that core functionality works at the server.
- If you have connections configured via the Information Design Tool (IDT) and they are not working from a local client machine or reports fail to run you can easily test the server's connectivity if IDT is available to you.
- If you are working with SAP Support on an incident they may want to isolate a problem to the server or to a specific client system. Having the tools available can facilitate quicker resolution time.
- If you have firewalls in between your servers and client systems it can be a very useful tool in narrowing down a problem to a network issue or a server configuration issue.
- If you have built a system to present a proof of concept having everything in one place makes it much easier to demonstrate the solution without moving from system to system to demonstrate features and capabilities.
I am sure you can think of many more reasons for one or the other. When I make a recommendation on this to my customers I explain the pros, cons, and risks of doing so. I also explain what the common practices are and then let them make the decision for themselves. My personal opinion is that I have every possible diagnostic tool available to me and i am inclined to install the client tools on at least one of the servers in the deployment.
