Yep, repackaging is easily introducing new issues. When you do that you should very well understand all possible aspects. In fact the xml files structure found as installation are helpfull/needed. Using the slilent install option. Is a nice one but is not complete - The configuration issues and more as of some fixes are still as "to do" - You are needing a shared location for the software depot (and responsefiles)      When the desktop management is outsourced or having several geographical locations this can become a big hurdle. - Having Flexed workstations or a VDI  approach you are getting into re-install needs.   When a install is lasting for more as an hour, the start of day of someday using it will be the first hours ... installing   You could focus on a laptop/notebook usage. This is good for many clients until you are not wanting data on that machine. SAS/Base foundation is becoming chased to get rid off that notebook. - Your doc reference is coming for a server (eip/baf) installation. That is Client/Server, the clients and server processes are sometimes strictly tied.       Needing to apply a fix can require updating the server and client at the same moment. Having possible several servers with different releases/fixes there is a need to support that at the clients also (different client versions).     The Deployment of SAS (software depot) is based on java and an tremendous lot of xml files calling possible several other tools. Java and an own development installation tool is not the most lucky combination. Java has incompablity issues and all the xlm file processing is slooooow.  53274 - Windows 8.1 Update 1 or Windows Server 2012 R2 Update 1 might cause batch commands for the SAS® 9.4 Deployment Backup and Recovery Tool to fail 52767 - Windows 8.1 Update 1 or Windows Server 2012 R2 Update 1 might cause a SAS® installation to fail and installed SAS® Java clients to not open Most of these issue hit in real life.  Yes, that is like a torture as Kurt has indicated.     ... View more