Query registry to get package success during task sequence

 Work  No Responses »
Aug 132012
 

When building a machine via a task sequence using either SCCM or MDT, there is no easy way to tell if a program has successfully installed or not. There is the option to halt the task sequence when an error occurs but this isn’t always preferable. you don’t always want a minor application halting the whole build.

Lets say that you want to make sure application A is installed before applications B and C get installed.  We can always look at the file system to check if the files or folders are there,  but this doesn’t guarantee that the application installed correctly, it might have copied the files but not added any registry settings or properly registered DLL’s.

A better way,is to look at exit state which the task sequence engine records in the registry. For this we can turn to PowerShell. This can be completed via script which is pretty straight forward with only one tricky bit, thrown in for fun.

The property that contains the status of a package is the _state key which resides in this location

HKLM\Software\WoW6432Node\Microsoft\SMS\Mobile Client\Software Distribution\Execution History\System\s0100100\GUIDLIKEKEY\_state

For some reason the _State property resides in a key that has a random GUID like name… not sure why, but it does.  This means that it is impossible to enter the value as part of the script.  Thankfully PowerShell helps get around this with two commands Get-childitem and Get-ItemProperty.  Using these commands we can find out what the GUID key name is at run time, which then enables us to check the value of the _State.

This script can be run from a task sequence command line using the following arguments to supply the PackageID.

Powershell.exe Registrycheck.ps1 ‘S0100100′

 

Now that we have got this information we can use it create task sequence variables to perform addition checks while the task sequence is running.   For information on how this work and a script that can be modified check out this post http://www.industrialarcservices.com.au/2012/07/03/script-to-clean-up-statestore-folder-only-if-load-state-was-successful/

If you have any issues please feel free to comment or send me an email – Martin @Industrial Arc Services com au

 

 

NOTE:

Only packages create registry keys.  Anything executed from a command line will not create these registry keys.

Powershell script to clean up StateStore folder only if load state was successful

 Work  2 Responses »
Jul 032012
 

First and foremost I want to say thank-you to Dylan at Virtual technology Solutions for helping me with all my PowerShell questions. Browse his site, use his very cool PowerShell Scripts, but maybe not the evil ones :)

I re-image machines virtually all day every day, but these are development and testing machines, and most of the times they are virtual machines.  This means that there is no data on them to lose, which means that I throw caution to the wind and re-image without care.

This carefree attitude comes to a grinding halt when actual users become involved. Whether they are testing, pilot or standard, I get very paranoid about losing anything which makes me double check and triple check before deleting anything. This paranoia gets even worse when I have to rebuild my wife’s machine who is professional photographer, let’s not go down that down rabbit hole…

This is where USMT comes in really handy. If you use USMT with the /nocompress switch it can offer you an easy fail-safe in case the load state process doesn’t run successfully.  This fail-safe takes the shape of the UserStateStore or if you are using the MDT toolkit OSDStateStore.  This unassuming folder has saved me quite a few times from having to say the following dreaded sentence to users ‘Sorry but everything is gone’

One of the other switches that you can use with USMT 4.0 is the /hardlink switch, which will dramatically reduce your scan state and load state times.  One down side however is that you will need to remove the statestore directory before you can re-run a build.  If the UserStateFolder folder is present the build will fail next time the scanstate process is run.   The solution to this is to delete the UserStateFolder, though this isn’t straight forward as the aforementioned hard links can cause files to remain locked. If you just delete the folder as normal you run the risk of corrupting the user’s data also.  This is why USMTUtils.exe has to be used to successfully delete the folder without any adverse impact on the user’s data.

USMTUtils.exe is a command line based program which is included as part of USMT 4.0.   There are many ways USMTutils can be  used to remove the UserStateStore folder,

  1. Manually via an administrators command prompt.
  2. Post build using a DCM and a batch file
  3. As part of the build task sequence as pre-build task
  4. As part of the build task sequence, run after the load state

This post will cover the 4th option, running USMTUtils.exe after and only if loadstate has been successful.  The easiest way to run USMTUtils.exe it set your task sequence to download and execute, and run a command line of

Echo Y | usmtutils.exe” /rd %OSDSTATESTORE%

This for me has one downside and one MASSIVE problem. The task sequence cannot be set to execute from DP which is my preferred setting,  and more importantly there is no checks to ensure that load state has run successfully and all the user’s data is where it should be.

This is when a PowerShell script, batch file, task sequence folders and a variables comes to the rescue.

First the PowerShell script.

The script is pretty straight forward, it looks a the last line for the loadstateprogress log for the words “Successful run”, if it is present then create a T.S variable called LoadStateCheck and set it to ‘True’ if not then set to ‘false’

Now the batch file.

This is a simple copy and execute affair.

Now too bring these scripts together into something useful

The thing that ties these two steps together is the creation of a variable called ‘USMTLoadStatSuccess’. This variable gets a value of True or false depending whether loadstate was successfully or not in restoring the user’s data.

This is what the steps look like.

  1. Set PowerShell execution policy to unrestricted
  2. PowerShell Script to create variables
  3. Batch file to copy and execute USMTutils.exe
  4. Create conditions for running USMTUtils.exe

 

Setting the default Chilean language using MDT

 Work  No Responses »
May 252012
 

Sometimes, I wish the world was flat and that we all spoke the same language!!!

This would eliminate the need for timezones as the sun would rise and set at the same time for everyone, and having a single language would make OS deployment so much easier.  Granted the lack of language diversity would also mean a lack of awesome cultures, and a lack of timezones would mean no more jet lag and getting up in the middle of night to talk to people in the antipodes… Actually that might not be such a bad thing.

ANNNNYWAY…

My current client has offices all over the world.  I use the term offices very loosely as some ‘offices’ are nothing more than a relocatable building on the cold wind swept plains of Mongolia or deep in the heart of Chile or the remote outback of Australia.  This makes localization critical as there isn’t much point having English installed as the default language when  users, primary and sometimes only language is Spanish.  This just causes unnecessary support calls asking how to change everything back to Spanish.

This localization of windows 7 deployments can be done in single image by using Microsoft Deployment Toolkit (MDT), and it’s customsettings.ini file.  This one little ini has more power than most people realise, and learning how to harness it will make any deployment so so much easier.

The problem I had was that the default language for Chile wasn’t being set.  I was getting the keyboard, time zone and  user location but not the correct language.  This mean that every time a user was logged in everything was in English, great for me, not for my hot dog  loving Chilean friends.  The cause and therefore the solution to this issue quite obvious really, it just took me longer to work it out than I would have hoped.

What my problem was… Chilean isn’t a lanagauge  but Spanish is!

I was trying to set everything to ES-CL which work for UserLocale, but not for  UILanguage and SystemLocal.

Once I changed customsettings.ini to have the following values for Chile

UserLocale=ES-CL
UILanguage=ES-ES
SystemLocale=ES-CL

Everything worked!

This is what my final customsettings.ini file looks like,

For testing different sites settings I change 10.0.1.168.190=Brisbane to 10.0.168.190=Santiago

Now that Chile has their preferred language set as default, I can get back to searching for the elusive babble fish which will make this problem disappear forever.

Bypass execution policy when running powershell scripts

 Work  2 Responses »
Nov 092011
 

Powershell has been designed with security in mind, you can’t just double click on script to run it.  Even when you right click and execute a script you need to first set the signing and execution policy.  This is as good thing, considering the power of powershell and the evil that it could do, I like it that way.

So this is why the following seems strange, I am not sure if it an oversite or it is by design.  What it allows you to do is, run a script by passing it line by line.  This could be useful is you want a scheduled task on a server without changing the execution policy for the user, something which might not be a great idea when scheduled  task as the system account.

You can use this to pass the script line per line.

Powershell.exe Get-Content ’C:ScriptsPigs.ps1‘ | powershell.exe -noprofile - 

The trick the script is the “-” on the end. Another way you could achieve the same result is to run the script with the following method powershell.exe -NoProfile -ExecutionPolicy Bypass -File However using  ’bypass’ will prevent any prompt and warnings from appearing,  IMO it is best to avoid this.

Running in a Task Sequence

The other situation which it could be useful is for running powershell scripts in  a task sequence.  Instead of setting the execution policy you can  ”(powershell.exe -Command { Set-ExecutionPolicy Unrestricted }” .

When using this in a task sequence you will need call the location of the script this can be called via in the following ways

If the script is a package then

Powershell.exe Get-Content ’.Pigs.ps1′ | powershell.exe -noprofile - 

Or if you add it to the MDT scripts you can use

Powershell.exeGet-Content  ’%deployroot%scriptsPigs.ps1′ | powershell.exe -noprofile - 

You will also need to add

“%systemroot%system32WindowsPowerShellv1.0″  as the start in location

Script to update prefix of computer name for OSD built

 Work  No Responses »
Nov 032011
 

Let me first start by saying that I am not great at vb script. I prefer powershell, not getting into the reasons why but I do.

So when a question was recently posted on myITforum about how to change the prefix of a computer name from XP to W7 I knew a script would be the answer. Not sure what made me think why not I will give it a go, but I am glad I did.

In terms of scripts it is very simple if the first two characters = XP then replace. As I said simple but there is something about producing a script yourself which is very satisfying.

Like most scripts the logging makes up the bulk of it.

PowerShell Script to create WinPe boot images

 Work  No Responses »
Oct 202011
 

Making WinPe boot images is one of those things that I need to do on a semi-regular basis, but unfortunatly not regularly enough to remember the syntax for DISM.  To over come this I created a PowerShell script to do it for me.

The script updates both x86 and x64 WinPe WIM files.

  • It checks to makes sure that the Windows Installation Toolkit is installed.
  • Creates  folders to mount this WIM files to
  • Takes a copy of the original WIM files
  • Mounts than adds the following components to the WIM file,  Scripting.cab and WMI.cab
  • Adds Trace32.exe and Trace64.exe into respective WIM file
  • Un-mounts the WIM.

Other components can be added like HTA and ODBC but since I didn’t need them I have rem-ed them out.

To add the Trace32.exe and trace64.exe  into WinPe create a folder called Trace in ‘C:Program FilesWindows AIKToolsServicing’

Both Trace32.exe and Trace64.exe are available here

http://blog.esmnetworks.com/operating-system-deployment/sms-trace64-and-trace32-for-winpe/

Check for wireless network in task sequence

 Work  1 Response »
Oct 062011
 

My current client has a requirement for some software deployments and all OS deployments check to see if a laptop is on a wireless network before running a re-image or deploying software.

This seems like it would be straightforward, check default gateway to see if the laptop is connected to a wireless subnet if so, then exit.  The problem is that laptops have multiple network adapters which means that the default gateway values are stored in an array which means that using a query like this in a task sequence won’t work.

SELECT * FROM Win32_NetworkAdapterConfiguration WHERE DefaultGateway  = ‘xxx.xxx.xxx”

You could write a script to check for the active network adapter, then find the default gateway value.

OR…

For both software being deployed via a task sequence, and OS deployment we can use the MDT toolkit to help us make this process easier.

The ‘Gather’ process works the same as its name suggests, it gathers information about the machine.  Thankfully one of the values it gathers is the default gateway.  The ‘Gather’ process also creates a variable called DefaultGateway001 which the current default gateway value gets added.

NOTE: The ‘Gather’ process must be run after the ‘Use Toolkit Package’  step.

Now to put all these words/gibberish into something practical

At the very start of a new or existing task sequence create the following,

  1. Create a new folder called ‘Wireless Check’
  2. Add the MDT task ‘Use Toolkit Package’
  3. Add Gather Task – no custom settings file needs to be added as we are using standard settings
  4. Create another folder with a name like ‘start install if not on wireless’
  5. on the Options tab add a condition, If Statement, Any
  6. Add Condition, ‘Task Sequence’ variable with the following details

Variable: DefaultGateway001

Condition: Not Equals

Value:  192.168.12.1

If you have more than wireless subnet repeat step 6 ensuring that they are all under the ‘If Statement’

Since we have selected ‘ANY’  as the condition we are able to enter multiple values for the task sequence engine to validate against.  This means that you could include server subnets to ensure that nothing untoward happens, like an in-place upgrade of your data centre to windows 7!

Create another folder under ’start install if not on wireless’ with all your steps for software install and or task sequence.

One downside to this method is that every deployment either to  a wired or wireless subnet reports as successful.  Which technically it is as it either ran the entire task sequence or it did run as it was on a wireless subnet so it also is a SUCCESS!!! :)

This  is a how a basic software distribution  task sequence looks

Task Sequence with Wireless check

Software Updates not installing during XP capture

 Work  1 Response »
Oct 062011
 

I know there are plenty of posts covering this subject, but the issue that I had was resolved with a combination of other peoples posts, trial and error and swearing. The last is bad for me but great for the swear jar.

The issue that I was seeing was that ‘software updates’ weren’t being installed during XP capture. The status messages where showing that the task was timing out. A quick search turned up this article which looked like a winner,

http://support.microsoft.com/kb/2009754

This sadly wasn’t the resolution.

After some more swearing and rejections, I found this article by nice guy and MDT source of knowledge Michael Niehaus

http://blogs.technet.com/b/mniehaus/archive/2008/12/10/configmgr-install-software-updates-task-failing-when-building-a-reference-machine.aspx

This article mentioned that SLP (Server Locater Point) might not be set.  The SLP is required when the capture task is running as client isn’t a member of the domain.  Makes sense, so I thought I would add the SLP=%sccmserver% to the installation properties.

More rejection followed with more swearing

What was making a it bit harder to track down the issue was that the package right before the software updates steps was an install of IE8, which was working like a treat.

However something in my brain wouldn’t let go of this SLP issue, it seemed to fit what I was seeing (or it could have been narcolepsy causing parts of my brain to fall asleep).

Since the SLP is required for clients to locate the Config Mgr server when it is a work group, and the SLP publishes it’s information in to WINS, (DNS is used with A.D)  I decided to have a look in WINS to see what is set there…

NOTHING, nothing was set there.  More swearing but for a good not evil.

This looked promising, could this be the cure to all my rejections and swearing issues I was experiencing.

Following this article which was written for SMS 2003 and client installation issues when AD wasn’t extended,

http://support.microsoft.com/kb/883620

I created the WINS entries for the SLP.  And with some intrepidation and low exceptions (the only way is up) I started another capture.

To my excitement I saw the “Install software updates” screen change from blank to the downloading updates.

My final captured WIM file increased in size from 457mb to 604mb, This makes me exited (sad I know) as I can now tell my client that the source WIM is XP sp3, IE8 and current patches, as I had promised.

The other thing that made me realise is, not to forget that SCCM is built on previous version of SMS, which means that back end has’t change that much.

Now what to invest the cash in swear jar on.  I am thinking a Penny Farthing!