Software Installation Using Group Policy Startup Scripts Recently I was engaged by a large Government client to investigate some issues with what they thought was some poorly packaged applications. The client had previously engaged an small external consultant operating under their own company and unfortunately they didn't really get what they thought they were paying for. During the time spent at this client site I identified a number of issues which I seem to come across quite often so I decided I'd write a blog entry on it. The background to this is the client had the SAPGUI application packaged by an external consultant. Anyone who knows SAPGUI knows for various reasons it can be a bit of a challenge to package. The vendor supplied installer for SAP not only installs differently to most other vendor supplied installers but it also does some funky things in areas such as add a heap of entries to the Services file found in%windir% System32 drivers etc Services. It also has a number of pre-requisit software products - such as the.Net Framework and two versions of the Visual C# Runtimes (2005SP1 and 2008SP1). These pre-requisits aren't so much the problem unless they're accidently captured and included within the main SAP package (which the previous consultant did) at which point I consider it to be a 'dirty package'. In this case, the situation is the client deploys their software (for the moment) using Group Policy Software Installation and the main symptom the client was reporting was the SAP application was initiating self-healing as well as reinstallation each time the computers started up. Initially I thought to look at areas such as Advertising information and user-based Components being located in machine level installed Features as well as the usual run-of-the-mill dirty and orphaned components which should have been removed. Initially I concluded a number of areas within the consultants MSI could be the cause of the problems as these are typically the most common causes for applications repackaged into MSI installers to produce these sorts of problems. I also made an assumption the consultant who did the packaging to have included the Services file in their package which is a big mistake. Unfortunately this assumption also turned out to be true. ![]() When I opened up the package in Wise Package Studio I discovered all of the above. Multiple features, dirty orphaned components which should have been cleaned out, pre-requisit components included in the main package (such as the Visual C# Runtimes, Visual Basic redistributables and.Net Framework components) as well as the Services file stored in the package as a file and not set as Permanent which means when the package is uninstalled it will remove the Services file completely along with the standard Windows entries. All of these mistakes could result in breakage of the clients SOE when the application is upgraded - which was one of my primary tasks for this engagement. ![]() The first thing I set out to do was repackage the latest version of SAP GUI correctly and cleanly. Doing so reduced the size of the compiled MSI from 180MB for SAP GUI 7.1 down to 90MB for 7.2. By ensuring the pre-requisit components -.Net Framework 3.5, Visual C# Runtimes 2005 SP1 and Visual C# Runtimes 2008 SP1 are handled separately as well as utilising Merge Modules for XML as well as a range of Visual Basic redistributables meant my SAP GUI package was shaping up just nicely. When I started looking at the existing Group Policy object which controls the Software Installation I discovered something very interesting - that being the Policy not only installs the software using the expected Software Installation type but there was also a Machine Startup Script defined.
0 Комментарии
Оставить ответ. |
АвторНапишите что-нибудь о себе. Не надо ничего особенного, просто общие данные. Архивы
Март 2019
Категории |