2way Technology

Configuration Manager, Windows 7 OSD, Scripting, Application Packaging, Windows Embedded, Microsoft Surface

Recent posts

Tags

Categories

Navigation

Pages

    Archive

    Blogroll

    Disclaimer

    The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

    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. I thought, what's this? Better take a look. What I found was the previous consultant not only setup the MSI they packaged to deploy as a Software Installation Policy but they also created a Machine Start-up Batch File to do the same. Only the consultant didn't think it through clearly because they failed to correctly handle the fact that the Script should only execute the installation if the software isn't already installed. Instead, the way the consultant set it up was each time the script ran it called the installation ragardless if the software was already installed - in other words, each time the target computers started up the script would run and the SAP GUI application installer would be re-executed and the SAP GUI MSI would be reinstalled over the top of the existing installation.

    Once the new version of the SAP GUI application had been re-packaged cleanly the next thing was to discuss with the client how they wanted to address the issues which would arise from uninstalling the previous packaged version of SAP GUI and ensure they knew the risks. At time of writing this blog entry the client is still considering all of the options I've suggested but what I can say is they're currently more inclined to re-image all of the PCs with the old package installed. This approach to me is major work and is avoidable, but the biggest thing it demonstrates is the dangers of inexperienced Application Packagers working in large environments. Unfortunatley it's not an isolated case and I have seen entire SOE fleets being reimaged due to poorly packaged applications.

    I guess the point of this Blog entry is to highlight the importance of building in logic within your Startup scritps if you're using them to install software to ensure they only run when needed. Make sure you Startup script checks to see if the application is already installed or not and only run the installation if needed. Startup scripts running things like Software Installations are becoming more common, for example Office 2007 installed by a Startup script instead of the native Software Installation policy produces far better results and Microsoft is even now providing a downloadable sample script.

    Posted: Aug 25 2010, 11:16 by Ben Fisher | Comments (0) RSS comment feed |
    • Currently 0/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5

    BPOS - Exchange Online Performance

    Well it's been a little over a month since migrating to Exchange Online supplied through the BPOS service offering.

    So far the service has been overall really good but I though it's important to share a few 'limitations' and perhaps bugs.

    Additional Mailboxes

    The first issue which has come to our attention is the support for Additional mailboxes. Whilst you can add supplemental mailboxes to Outlook there are a few steps you have to do in order to setup the security permissions. To enable your primary mailbox to have access to additional mailboxes you have to execute a PowerShell command which grants Full Control and SendAs rights. This is no so bad as the PowerShell script works and all you have to do is use your variables. Microsoft has the syntax documented here: http://www.microsoft.com/online/help/en-us/helphowto/f83a224b-53c5-48b4-8e72-327571c4555e.htm

    Add-MSOnlineMailPermission -Identity user@example.com -Credential $cred -TrustedUser admin@example.com –GrantFullAccess True –GrantSendAs True

    The next thing you do is add the account to your Outlook as a secondary mailbox, this you do as you would normally.

    Where the 'bug' appears is Outlook struggles to open emails which are bigger than a typical size email in particular emails which contain attachments over say 500KB. If you try to open an email with say a 3MB attachment you might as well go away and make yourself some lunch because Outlook takes a long time to open the email. If you try to save the attachment locally you also notice the same performance issues. I've noticed these issues don't exist if the email is in the primary mailbox.

    Posted: Aug 05 2010, 15:51 by Ben Fisher | Comments (0) RSS comment feed |
    • Currently 0/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5