Create a bootable USB pen for SCCM Windows 7 Build Deployment

If you are ever in a situation where deploying your OS by SCCM's more conventional methods (ie PXE or LAN based deployments) isn't feasable (bandwidth/no connectivity) then you can prepare a USB pen and deploy to machines via a USB boot.

I've found the SCCM built in method of making a USB pen to be quite unreliable so I opt for the manual method.

Just a few heads up first:

• I'd recommend at least an 8GB drive but in reality your build (if corporate) will eventually exceed this.
• The pen will be totally wiped clean - all data will be lost.

Step 1:  Preparing the USB pen

1. Open command prompt
2. Type diskpart and press enter
3. Type list disk and press enter
4. Find your disk in the list
5. Type select disk * (* being your number)
6. Type clean and press enter - you should see "DiskPart succeeded in cleaning the disk."
7. Type create partition primary and press enter - you should see "DiskPart succeeded in creating the specified partition."
8. Type select partition 1 and press enter - you should see "Partition 1 is now the selected partition." 
9. Type active and press enter - you should see "DiskPart Marked the current partition as active."
10. Type assign and press enter - you should see "DiskPart successfully assigned a drive letter ..."
11. Type detail disk and press enter.  For this example we will work with a drive letter "U" for USB
12. Type exit to leave the Diskpart command and return to a standard prompt

Step 2:  Formatting & Copying

We are still using a drive letter "U:" so we want to type:

format U: /fs:fat32 /q YOU WILL LOSE EVERYTHING ON THE PEN HERE

Enter a label for the drive - this is how it will show in "Computer"

I copy the files manually - it works - but if you want to do it "properly" use this command:

In command prompt navigate to the location of your build files - this is what would have been extracted from the ISO that was produced in SCCM when you "Created Removable Media" from the OSD task sequence - if you need a guide on this mail me or leave a comment...

Type xcopy \*.* /s/e/f \ 

With our extracted ISO in C:\Win7Build and our pen being U:\ This would look like:

Type xcopy c:\Win7Build\*.* /s/e/f U:\ 

Don't forget you may/will need to adjust the boot order in the BIOS to accommodate booting from USB - you can find a guide here: http://bit.ly/TvndIW

Parking Fail

Have a look at a group I like on Facebook - great for shaming those parking fails we all hate!

www.facebook.com/officialparkingfail

Java Deployment (x86)

I've spent many hours searching the net for a definitive guide on how to successfully deploy Java across a network and to newly deployed machines.

In this instance I'm trying to add Java to an Operating System Deployment using Microsoft SCCM with two particular settings automated into the deployment.

I want the automatic updates to be disabled as this is constantly screwing up our clinical systems that get delivered to the users desktop as an update of Java resets several settings we have to configure post install.

The other is the Proxy set to "Direct Connection" as again our clinical systems hate any interference from the Proxy settings.


I've decided to repost my steps here in hope that it will help a fellow tecchy one day:

• Download your choice of Java - I'm using 1.6.0.31.

• Run the.exe and run to C:\Users\\AppData\LocalLow\Sun\Java\jre1.6.0_31

• Copy the Data1.cab and jre1.6.0_31 files out of there into a folder of their own.

• I already have a working WIM image I captured last week and didn't want to go through another capture so using the DISM GUI tool  I mounted my WIM and added a folder structure and the deployment.properties file to: C:\Users\Default\AppData\LocalLow\Sun\Java\Deployment.  Other settings for the deployment.properties file are available here.

• Within deployment.properties was the following - it's actually one I created by manually altering the settings from the Java control panel and capturing the file from C:\Users\[username]\AppData\LocalLow\Sun\Java\Deployment

#deployment.properties
#Tue Apr 13 13:59:54 BST 2010
deployment.version=6.0
deployment.proxy.type=0
deployment.javaws.autodownload=NEVER
deployment.javapi.cache.update=true
deployment.security.mixcode=DISABLE
deployment.browser.path=C\:\\Program Files\\Internet Explorer\\iexplore.exe
#Java Deployment jre's
#Tue Apr 13 13:59:54 BST 2010
deployment.javaws.jre.0.product=1.6.0_31
deployment.javaws.jre.0.registered=true
deployment.javaws.jre.0.osname=Windows
deployment.javaws.jre.0.platform=1.6
deployment.javaws.jre.0.path=C\:\\Program Files\\Java\\jre6\\bin\\javaw.exe
deployment.javaws.jre.0.location=http\://java.sun.com/products/autodl/j2se
deployment.javaws.jre.0.enabled=true
deployment.javaws.jre.0.osarch=x86

• I committed the changes to the Wim and uploaded it back to our deployment server :::EDIT::: DON'T FORGET TO UPDATE THE DISTRIBUTION POINT!!!
• Created a package for Java 31
• Used the command line for the package program: msiexec.exe /i jre1.6.0.31.msi /qn
• Hey presto - I'm now getting a Java deployment that automatically uses the settings defined in the deployment.properties file I created! BOOM !!!

OnContentAvailable program 0x80091007

Symptoms:

When deploying software to a collection the client execmgr.log shows the following error:

OnContentAvailable program 0x80091007

You will notice a hash mismatch also " SoftDistAdvertHashMismatchEvent" - when checking the CAS.log you will see

"Hash matching failed."

Cause: 

SCCM is a temperamental bitch

Solution:

Goto the package in question and right click on Distribution Points and click "Manage Distribution Points".  Choose "Update all distribution points with a new package source version" - and thats exactly what happens.
Kick of a hardware policy cycle on the client and watch the magic.

SCCM using wrong drive as distribution share

Due to the unnecessarily greedy nature of SCCM if when you create a package distribution point there is more than one drive available to the server it will always opt for the drive with most space.

Our server has 3 drives:

C:\ = 50GB System Drive (for OS etc)
D:\ = 200GB Data Drive (for package storage etc)
P:\ = 50GB Page File (it's an old VM)

It got to the point where our data drive got to 151GB capacity (49GB free) and discovered that the P:\ drive actually had 50GB available.... So it helped its self and created an SMSPKGP$ folder and proceeded to fill it up.

Then when P:\ got to 10GB free it realsied that C:\ had about 40GB free and proceeded to create a SMSPKG$ folder and so on and so forth.

This only became apparent to me after it had been utilising this space for a while so I discovered a nice little easter egg that isn't widely publicised by M$.

If there are drives on your SCCM server you don't want it to use simply create a file on the root of the drive named

NO_SMS_ON_DRIVE.SMS

I've seen various versions of this listed on different sites such as "nosmsondrive.sms"; let me tell you now - this doesn't work (or didn't for me).

I know now that the correct syntax is NO_SMS_ON_DRIVE.SMS as I had a "Install retrying" notice on an AppV package DP install and it stuck until I deleted this file.

Hope this can help someone else one day...

C

Armed forces hits

Really proud to be getting hits from the boys and girls overseas in the forces.

I hope my posts can help you and in turn I thank you for all the hard work you are all doing.

Be safe!

C

Turn on logging for MSI installs

If you ever install from MSI's (which I'm sure you do) it can be handy to turn on logging so you can see the outcome - particularly handy if the install is failing.

Use the following code after your package.MSI and then a log file will be generated at the location you choose:

msiexec /i Packagename.msi /l*v c:\logname.log

Drop Box

I need some more DropBox space - please sign up here using my referral link and install it so I get some more space :D

db.tt/OlhgzLZ

Cheers loyal readers :)

PXE & OSD Builds Failing - conflicting records

If you have ever had issues with your PXE boot failing when you try to rebuild a machine that already exists within SCCM then this may help you out.

I'd been spilling over this one on and off for a while when I discovered that these machines were appearing in "Conflicting Records". 

Conflicting Records within SCCM console

You have a few options here.  We can get SCCM to manage conflicting records by chaging the setting site wide:

1. Navigate to System Center Configuration Manager / Site Database / Site Management / <site code> - <site name>
2.  Right-click <site code> - <site name> and then click Properties. 
3. Under the "Advanced" tab, you can choose Manually resolve conflicting records or Automatically create new client records for duplicate hardware IDs.
4. OK

Another option is to manually resolve conflicting records:

From conflicting records as above select the conflicting record and look in the actions pain and you will see  few options:

1.  Merge - combines the new record with the existing one merging together
2. New - creates a brand new record for the conflict
3. Block - creates a new record but blocks it

Then there is another really cool way of doing it!!

•  Save this into a file called "Merge.vbs" to somewhere of your choice - we will be using it in  a few steps time - don't forget to check your formatting if you copy and paste - the "quotes" can sometimes 'mess up' etc

Dim swbemLocator
Dim swbemServices

Main()

Sub Main()
Dim oProviderLocation
Dim oLocation
Dim oReg
Dim oPendingRegs
    Set swbemLocator = CreateObject("WbemScripting.SWbemLocator")
    swbemLocator.Security_.AuthenticationLevel = 6 'Packet Privacy.
    Set swbemServices = swbemLocator.ConnectServer(".", "root\SMS")
    Set oProviderLocation = swbemServices.InstancesOf("SMS_ProviderLocation")
    For Each oLocation In oProviderLocation
        If oLocation.ProviderForLocalSite = True Then
            Set swbemServices = swbemLocator.ConnectServer(oLocation.Machine, "root\sms\site_" + oLocation.SiteCode)
        End If       
    Next

    Set oPendingRegs = swbemServices.ExecQuery("SELECT * FROM SMS_PendingRegistrationRecord")
    For Each oReg In oPendingRegs
        Resolve 1, oReg.SMSID
    Next

End Sub

Sub Resolve(action, SMSID)
Dim InParams
    Set InParams = swbemServices.Get("SMS_PendingRegistrationRecord").Methods_("ResolvePendingRegistrationRecord").InParameters.SpawnInstance_
    InParams.Action = action
    InParams.SMSID = SMSID

    swbemServices.ExecMethod "SMS_PendingRegistrationRecord","ResolvePendingRegistrationRecord", InParams
End Sub

• Ensure that conflicting records on the advanced tab of site properties is still set to "Manually Resolve Conflicting Records"
• Create a new status filter rule with the following properties: 

Component : SMS_DISCOVERY_DATA_MANAGER
Message ID: 2642

• On the actions tab select "run a program" and specify the above script we created.  If on a x64 server you may need to specify the full path to "cscript.exe" i.e. “C:\Windows\SysWOW64\cscript.exe C:\SCCMTools\Merge.vbs”

Relying on the status filter rule will mean that the script will only run when it detects the 2642 event however you can run the script manually if you want to tidy up what is already there.

I have to thank a great SCCM consultant; Dean Lockwood at BDS services for this - although he will tell you it was my inspiration that prompted the outcome ;)

Task Sequence Fails Error 0x80040104

More fun and games with OSD Task Sequences - this time in the form of error 0x80040104.

The error as it was displayed on the clients screen was:

This task sequence cannot be run because a package referenced by the task sequence could not be found. For more information, please contact your system administrator or helpdesk operator.

This happened immediately after selecting the task sequence and processing the dependencies.

Upon viewing the SMSTS.log we spotted the error

Failed to resolve selected task sequence dependencies. Code(0x80040104)


The only change made to the TS since yesterday was a new driver package for the Lenovo X220T tablets.  The reference to a missing package reminded me of a post I made once in reference to drivers and driver packages - that if you leave the distribution point on Source version 1 it will just bomb out.  Refreshing the DP didn't help so went via "Manage" and created a new source version.


As if by magic..... It worked!

SMSTS.log

It's all quiet..

Not many people leaving comments here - be great to hear if any posts have helped you :)

verifying content availability for package optional program *

I have a task sequence setup for quick deployment of corporate apps to machines that haven't yet got complete driver packages and get a vanilla install of Windows 7 x64 deployed.

This TS was recently failing when run from "Run Advertised Programs" with the error:

verifying content availability for package optional program *

It turned out my Java Package didn't have program selected due to the it being disabled from the actual packages program its self.  I've highlighted it below.  If you do get the error it's worth checking your TS programs - unfortunately SCCM doesn't always give the most comprehensive of error messages - I hope this helps someone else.