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.

    Hyper-V No active network adapters found

    Recently I installed Hyper-V R2 onto a Lenovo T510 Laptop to be used as a Wise Package Studio Application Packaging Server.

    This is somewhat of an inexpensive server to support two packagers working on site for a Government client for a short period of time. The short story is, they want all of the packaging to be performed on site but they don't have any packaging infrastructure.

    Option "A" is to take a DL360 G4 server onsite and work off that but the simple fact is the two quad-core CPUs and 15K SCSI disks are a bit too heavy and noisy to work with. It's also a bit much to ask my staff to carry a 1U server with them to a client site along with everything else they need to take.

    So the answer is we have a Lenovo T510 Laptop running the Core i7 Quad-Core with 8GB of RAM. It has Hyper-V 2008 R2 installed straight onto the disk (not Server 2008 R2 with the Hyper-V Role) and from there it has a Windows Server Guest running DHCP (for the packaging clients) as well as SQL and Wise Package Studio. There is enough resources left to run a Guest Windows 7 client or two for packaging and testing if needed but the idea with this is to use the Lenovo Laptop as a mobile Wise Package Studio server setup which our Packaging staff can easily take with them for on-site packaging engagements.

    In order to get Hyper-V working on the T510 there was a couple of steps I had to do:

    1. Enable Virtualisation in the BIOS

    2. Install the Network Drivers into Hyper-V.

    On the T510 Laptop, the drivers for the NIC are not available in the Hyper-V R2 install WIM and the Windows 7 x64 drivers from Lenovo don't work with Hyper-V. In the end, the solution was to download the NIC drivers from Intel from here: http://downloadcenter.intel.com/confirm.aspx?httpDown=http://downloadmirror.intel.com/18725/eng/PROWinx64.exe&agr=&ProductID=&DwnldId=18725&strOSs=&OSFullName=&lang=eng. I then had to use the Hyper-V pnputil command:

    pnputil -i -a e1k62x64.inf

    Once this command was run the Intel 82577LM Gigabit Network Adapter was installed. From here was a simple case of installing a Guest Virtual Machine using the Microsoft Hyper-V Manager as part of the Remote Administration Tools for Windows 7.

    At this stage the mobile packaging server is working well.

    Ben

     

    Posted: Mar 09 2011, 21:39 by Ben Fisher | Comments (0) RSS comment feed |
    • Currently 0/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5

    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

    Packaging Hardware Drivers & Vendor Supplied Installers

    Recently a client requested for some touch-screen software to be repackaged to enable silent installation onto their digital signage platform. In a nutshell, the touch-screen is a piece of hardware that once installed presents to the Operating System as a mouse and as part of the vendor supplied installation exe a driver is also installed. Upon initial investigation I quickly discovered the vendor supplied installer requires a system restart and if you follow the installation process documented in the setup manual it says to install the software prior to connecting the hardware, then once the hardware is connected you need to run through the 'Add New Hardware' wizard.

    Well, let me tell you this is an inefficient and more complicated process than it needs to be, most of which can be eliminated through Software Packaging (also known as Application Packaging) using products such as Wise Package Studio.

    In the case of the touch-screen software and driver I was able to prevent the reboot requirement as well as the need for running through the 'Add New Hardware' wizard. If you were to use the vendor supplied installer the four-step process would be as follows:

    1. Install software (Vendor supplied software installation)
    2. Restart system
    3. Connect hardware
    4. Install driver

    By repackaing the software installation into a custom Windows Installer MSI, I reduced the total number of steps down by 50% to the following two-step process:

    1. Connect touch-screen hardware via USB
    2. Install software (repackaged Windows Installer MSI)

    Because I used a method of what we refer to as 'driver injection' or 'preloading', the hardware can either be present (connected) or not. If the hardware is not present during the installation, the driver is preloaded into the driver store and when the hardware is connected the device is immediately initiated by the system and becomes ready to use because the driver is already present, similar to standard devices with built-in drivers.

    There are a number of factors to consider when repackaging software, in the case of the touch-screen software and driver it was a relatively small application and single driver. Eliminating the need for a system restart was achieved by two things - ensure the new services installed were started and; make sure the driver is properly installed, both of these were not adequately catered for in the vendor supplied installation. It didn't preload the hardware driver and it didn't start the services it installed, both of which are required to complete the installation process. The other issue I found was the device driver wasn't written correctly and the INF installer file needed some adjustment because it didn't point to the correct location for the driver .SYS file.

    Repackaging software offers great benefits over using the standard vendor supplied installers including the ability to customise the installation - such as add and remove features as well as streamline the installation and setup process. In many cases, smaller vendors - such as the case of Zytronic (maker of the Zytouch Touch Screens) as they don't specialise in software packaging it's common to find their software installers lacking features and capability and in number of cases I've seen vendor supplied installers which can only be described as downright rubbish - if not harmful to your computer.

    If you're looking for expertise to package (or repackage) your software installations, contact 2way Technology on 1300 66 99 23.

    Posted: May 10 2010, 15:20 by Ben Fisher | Comments (0) RSS comment feed |
    • Currently 0/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5
    Filed under:

    Wise Package Studio 8 Released!!

    The leading Application Packaging software product, Wise Package Studio version 8 has finally been released. This new version brings a number of new features, the most important in my opinion is support for 64bit and improvements for packaging on Windows 7 or for Windows 7. You can get more information, including a Free Trial of the product here: http://www.symantec.com/business/package-studio.

    I suggest you keep a watchful eye on the known issues list:

    Known issues in Wise Package Studio 8

    Wise Task Scheduler issue. If you install Wise Package Studio Professional, and later add an Enterprise Management Server license, the shortcut to Wise Task Scheduler (an Enterprise feature) is not added to the Start menu.

    Altiris SVS Applet. The Altiris SVS Applet context-sensitive help does not work. By default, the help for the Altiris SVS Applet is installed in the C:\Program Files\Altiris\Software Virtualization Agent directory.

    SetupCapture. On a Windows 7 computer, SetupCapture hangs when capturing an .EXE with self-registering .DLLs if the Enhanced File and Registry Key Association option is checked on the General Settings tab.

    Firewall Exceptions. In Windows Installer Editor, on the Firewall Exceptions page, you cannot add a Firewall exception to a feature with a condition.

    Display Message action. In Windows Installer Editor, if you add a Display Message action in the Execute Immediate sequence, the message appears behind the progress dialog box on Windows 7 and Windows 2008 R2 computers.

    Media page. In Windows Installer Editor, on the Media page, if you select the Quickest option to create external CAB files, multiple cab files are not created for .WSIs.

    29212: If you uninstall Wise Package Studio and re-install it, the Altiris Software Virtualization Agent (SVS Agent) does not get reinstalled.

    • To prevent this problem, uninstall the Altiris Software Virtualization Agent before you uninstall Wise Package Studio.
    • If you uninstalled Wise Package Studio without uninstalling the Altiris Software Virtualization Agent first, then start Virtual Package Editor and you will be prompted to install the agent.
    Posted: May 06 2010, 16:49 by Ben Fisher | Comments (0) RSS comment feed |
    • Currently 0/5 Stars.
    • 1
    • 2
    • 3
    • 4
    • 5