HP 3D Driveguard 6 in SCCM OSD Windows 7 x64 Task sequence

Back again with this issue, HP have released a new version of driveguard and this version has even more problems than the previous.It's taken me a bit of time but I've had to figured this out all over again :)

At the moment this guide works with the following models:

HP Elitebook 820 G1
HP Elitebook 850 G1


It most likely will work with many more, as HP tend to release a driveguard update every new generation of device. For this package I'm using sp64934.exe. If you are trying to automate an older version, see my other post.

Step 1) Download SP64934.exe from the HP support website.

2) Extract sp64934.exe with Winrar or 7-zip. Inside you will find another setup.exe file.




3) From an elevated command prompt, Extract the Installshield setup by running:

setup.exe /a /s /v"/qb TARGETDIR=c:\test\

You are now left with an MSI based setup in this folder:

  

4) Copy these files to your SCCM Distribution share and create a package with these files.




5) Within the package create a program “Install HP 3D Driveguard”  with the following command line:

Msiexec /i “HP 3D Driveguard.msi” /qn Reboot=ReallySuppress

6) Download Visual C++ Redistributable for Visual Studio 2012 Update 4 from here
http://www.microsoft.com/en-ca/download/confirmation.aspx?id=30679
Put this file inside your package source.

7) Create a new program in your package call “Install MS Visual C++ Redist 2012” with the following command line:

vcredist_x64.exe /install /quiet /norestart

 

8) Add to your task sequence as two separate steps – run the Visual Studio C++ first, then the driveguard. remember to use a WMI query to filter the install.

 9) import the "HP Mobile Data Protection Sensor" Driver to your driver package for the model you intend to build. You will find this in accelerometer.inf in the "Drivers" folder in extracted MSI files.

Now when you run the MSI, the drivers will already be present on your system and you will simply be installing the service to go along with them.

That's it! If this post helps you, please give me a +1 thanks!
 

HP 3D Driveguard in SCCM Windows 7 Task Sequence

UPDATE 18/01/2014 - as of HP Driveguard version 6 the below guide will no longer work. HP have changed the package and released yet another broken installer upon us. I've figured this new version out and you can read the latest guide here:HP Driveguard 6 Guide.
 

This was a real pain, one of the last things on my "to-do" list for the build I was creating was to fix the program called HP 3D Driveguard.

This solution works with the following models/packages that I know of, others are likely supported as the same .exe files are used across different HP ranges.

2530p	sp47282.exe
2540p	sp53795.exe
2560p	sp53795.exe
6930p	sp47282.exe
8440P	sp53795.exe
8460P	sp53795.exe
2570p	sp57318.exe
8470p	sp59282.exe
9470m	sp59282.exe

In the past this would have been the kind of little OEM utility I would have totally ignored,but after reading about it, the benefits are pretty clear. In a nut-shell, the software provides free-fall protection for the hard disk on supported HP systems. The HP Elitebook series motherboard is equipped with an accelerometer which providing the driver is installed, instructs the disk head to "Park" when the computer is either in free-fall or being moved around. The end result is that you have fewer disk failures, which will translate into fewer man-hours being spent recovering data, logging calls with the OEM and then rebuilding the notebook.

Now, to make this clear, there is no problem to install this software either manually or via Altiris or SCCM, the issue I'm writing about today only occurs when building the PC with an SCCM task sequence.

The software is packaged with installshield and automated installation is rather easy with just the using these switches:

sp53795.exe -s /V /qn

The installer is designed to be able to pass switches into an internal MSI file (as indicated by the /qn switch) but even this doesn't seem to work correctly as it runs in passive mode rather than full silent mode. In an SCCM task sequence this fails to install completely.

Some Installshield packages can be flaky and require logging to be enabled, so I tried enabling logging by adding the /f2 switch, but still got the same error.

After loads of different approaches including putting the switch into a batch file, installing via "run command line" I still couldn't get this working. Although the OSD task sequence doesn't halt, looking back through the logs I can see that errors occurred.
Eventually I found the way to get this working and here are the steps:

1. Extract the .exe file with Winrar
2. Inside the folder you will see several files:

     3. Open up the command prompt and browse to this folder, enter:

      setup.exe /extractall

This will leave you with even more files, including.... two MSI files!

    4. Now you need to create a package in SCCM with all the files inside this folder.

 5. Within this package create a program as below:

The full switch is:

msiexec /i HPMDPAI3264.msi /qn REBOOT=ReallySuppress TRANSFORMS=HPMDPAI3264.mst

     6. Lastly, add the program to your OSD task sequence.

Ensure to tick the "continue on error" check box, the program will error during the installation, I believe this is caused by the suppression of the reboot.

And that's it folks. All very easy and intuitive eh? Why didn't we know how to do this straight off the bat? For me this is just another area where SCCM seems to behave very differently than normal automated installations. There is always the option of installing this software after OSD without having to go through all of this, but let's face it - if you go to the lengths of automating a full build, why would you settle for this?

So, you finally got it working and then logged onto Windows 7 but found no resident tray-icon? It appears HP are no longer doing this, if you want to check it installed successfully, look in the Programs and Features menu in control panel.

Hopefully this information is helpful to someone, and saves them the hours it took me to figure this one out.

Andrew

SCCM Operating System Deployment Task Sequences

In  the past few months my business has been working on the move away from XP/Altiris to a Windows7/SCCM 2007R3 environment. I was working closely with an outside contractor to get the infrastructure in place and getting SCCM up and running, but before this was even completed I was tasked to begin considering how to perform operating system deployment (OSD). Looking at SCCM from a newbie perspective I will talk about the challenges I faced in getting my OSD to work successfully.

After some investigation I soon found out that SCCM offers multiple ways to deploy an operating system to new machines and also machines already on your network. So far I have tested and implemented the following:

• PXE boot environment with unknown computer support - I have put a password on this at the moment so that users can't unknowingly image a newly added machine. This is useful where you might be in a scenario where you unbox and build multiple machines at one time, you really don't want to be messing around writing down MAC addresses to import for hundreds of PCS at a time.

• Bootable WinPE CD/USB stick, this method means you don't have to enable a PXE server on the network and is useful in environments like mine that already have multiple PXE servers. Unfortunately this means you will have to manually import the machine MAC address and put it into the OSD collection before it can be installed.  The disadvantage here is that you end up with a duplicate system in SCCM once it is renamed, but providing you have scavenging set up it should disappear reasonably quickly.

• If the PC you image is an existing PC with a previous OS (WinXP) you can simply for an install of the SCCM Client and then put the machine into the OSD collection. This can be very handy, but again it will create a duplicate machine in SCCM, which will be marked as "obsolete". This appears to be by design to avoid endless build cycles.

• Stand-alone task sequence media on CD/USB stick for the entire task sequence onto a DVD - this method works well for remote/small offices that don't have any server infrastructure, but SCCM task sequences can be rather large, in my case I need 3 DVDs worth to fit my standard image. It looks like high capacity USB flash drives are more feasible in this scenario.

Task sequence media is easily created, simply go to "Operating System Deployment" > "Task Sequences" > select your OSD task sequence and click "Create Task Sequence Media"

You can then select the type of media to create or create an ISO of the image for later use. Coming from an Altiris background I have to say I was very impressed easy this was and how well this solution worked.

I've got ahead of myself a little bit here, the largest part of this was the creation of the task sequence to begin with. I was fortunate that I had a base Windows 7 install.wim. Unfortunately it had only been tested on a handful of different models of PCS. After an evaluation of my asset management database I found that I actually had 11 distinct types of desktops that would support Windows7 in my environment. At this point I got a bit of headache, thinking back to Altiris and the multiple images for Windows XP. I wanted to get away from this and have "one image to rule them all".

One Image to Rule them All

The first thing I did was to test my Boot.wim with each device to ensure two things:

1. Each device could successfully boot to WinPE image.
2. By pressing F8 during PE boot and using the command prompt I could verify that WinPE could see the Hard Disk Drive and Network Card.

Fortunately all devices booted to WinPE without issue, but some were missing the network card driver or storage controller. These would have to be injected to the Boot.wim before we could continue. This can either be done by mounting the image using DISM in Microsoft MDT2010, or in SCCM you can go to "Boot Images" > right click on your boot.wim and go to properties, then press the "Windows PE" tab, press the "Sun" icon and then select the drivers you want to be injected. In order for the drivers to appear on this list you will have to firstly import them.

Now I had a working preinstall environment I could then begin testing deploying my main image. The next thing I done was to visit the manufacturer websites and download all existing drivers for the products I wanted to move to Windows 7. I downloaded the drivers for eleven models in total and stored them neatly on my SCCM server, sorting by model and device type. I then had another decision to make.

Order Vs Chaos

After some research it would appear there are two ways to approach driver management. One being "Chaos" whereby you simply import every driver possible and then allow every machine being built to scan then entire available driver database.  The "Order" solution is a very controlled environment whereby you import drivers for each model into a package and apply only that specific package to its relevant model. Being lazy I liked the sound of Chaos, but In practice I found this method to be much slower at building machines; the more drivers there are available the longer Windows takes to sort through and determine which driver is the most suitable.

Fortunately, SCCM makes importing drivers very easy. Simply create a new folder in the drivers section, right click, select import and browse to the location you stored the drivers for that specific model.

I was surprised to find that even when you select x64 drivers only that the packages also seem to contain XP, Vista, x86 drivers too. If you are going to import the packages for an x64 image like mine make sure to remove these drivers.

Either click new package to create a specific package or select an existing package, ensure to tick "Update distribution points when finished" to ensure your drivers get sent to PXE for immediate use.

Trying to adopt the "Order" method was causing me to run into issues. SCCM doesn't like it when you try to import a duplicate driver. It turns out that it's quite common for several HP laptops and desktops to share the exact same hardware, this was causing an error when trying to import this driver even although I just wanted to put that driver into my specific machine package. To get around this I installed patch KB2213600 which will allow SCCM to import duplicates.

With this method I was left with eleven different driver packages which I could apply. The next question would undoubtedly be how does SCCM know to apply that specific driver package? 

Using  a WMI query to select the model name from the system bios as a condition for installation allows only this package to be installed.

It's not only drivers that benefit from this functionality, what about the differences in software between laptops and desktops? You won't want to install certain software such as a VPN client or a mobile connectivity suite on your desktops!  Luckily there are a couple of easy ways around this.

Below shows and example using the "IsLaptop" variable - note that this is only availble when you have MDT integration. Before checking for this variable you will need to perform a "Use Toolkit Package" and  a "Gather" from the MDT menu. 

This also seems to work bothways. IE you can use "isDesktop"

You can also check for the presence of a battery.

Hardware Based Applications

When I had created all my packages and performed some test builds I noticed that there were some systems that just wouldn't install the drivers without its accompanying piece of software. ATI and Nvidia graphics packages seem to be the worst culprits, as both rely on their "Catalyst control centre" and "Nvidia Control Panel" to offer any advanced functionality. Bluetooth drivers were also the same as each device requires its own custom Bluetooth stack. I read elsewhere that these types of programs were called "Hardware based applications" being that they blur the lines between drivers and software. I found the simplest way to deal with these is to treat them like any other piece of software. Referring to the suppliers documentation *cough* and after fiddling about I found all the required silent install switches.

So far I'm about 90% there towards finalising the build. There are always little tweaks to go back and add. The other big part of this will be a brand Active Directory/Group policy re-structure which will go a long way to configuring this build. I don't want to add too many registry fixes into the build, but inevitably these will keep coming. At this point my OSD task sequence looks like this.

Please note that grey items are currently disabled experimental steps I was toying with. In the end I don't think I really need these. Using the above I can perform a zero touch installation on a new out-of-box PC or reimage an existing machine by simply dropping the PC into the OSD collection.

Like I said, I'm still an SCCM newbie and I would appreciate any advice on improving this.

Andrew