Month: April 2009

MMS 2009 – Day 3

Posted on Updated on

Nothing quite as siginificant on Day 3 of MMS.  Most of my sessions were to gain a better understanding of how SCCM, being extended with MDT 2010, helps “significantly” improve OS deployments.  Unfortunately, I don’t see how the additions can help; part of it is probably that the environment  of the systems [at our company] doesn’t have a need for some of the things.  In a brief discussion with Mike Niehaus, he tried laying out some of those things for me in the form of “Have you ever wanted to try to do insert challenge here with SCCM but couldn’t?  Check out MDT”.  But everything he listed were things I could already do in SCCM or had not interest in doing.  What I took away from the conversation was that if I ever think about how to do something out-of-the-box with SCCM, then I should check to see if MDT can already do it; which is a good take away for me.

MMS 2009 – Day 2

Posted on Updated on

The first session of the day is always one of the better sessions of MMS – the SCCM State of the Union – an all emcompassing update on what has changed to SCCM in the last 6 months and what is coming up in the future.  A couple of big takeaways are that SP2 will need to be installed in order to have support for Windows 7, there has been significant in the arena of Client Health, and SCCM v.Next eliminates its dependency upon the MMC consoles (which is a huge plus as the console frequently fails).

USMT 4.0 seemed to be the hottest topic on the day as it was talked about in nearly every session that I attended.   The new version has significant enhancements and improvements that (from my opinion) should be implemented right away.  During one of the BOF (open participatory) sessions, I learned about some of the challenges of the previous versions from real-world-admins in the room and then heard from Microsoft how the new version rectifies them.

MMS 2009 – Day 1

Posted on Updated on

Just completed day 1 of the Microsoft Management Summit.  My biggest takeaway from the day is the realization of how simple PowerShell can be to learn, and how useful it can be for automating tasks or getting dynamic system information that isn’t natively possible in SCCM (like getting active process usage throughout the day and exporting to a .csv file).  PowerShell can easily be used to gather information for short term tasks rather than extending SCCM inventories (which would need to be a long-term investment).  Additionally, PowerShell can still be used to create COM objects (like WScript.Shell in VBScripting) to accomplish tasks, which will help in the transition.

I also had a brief opportunity to talk with a couple of people with MyITForum (one being the great Rod Trent).  Hope to be able to run into some more.  Especially hoping to meet some of the MVPs in the SCCM realm!

Looking forward to day 2!

Handling Chassis Types In SCCM OSD

Posted on Updated on

One of the challenges with condensing workstation task sequences into a single task sequence is being able to distinguish between desktops and laptops as each typically has their own set of functions to perform when being imaged.  One of the best ways to determine this is by querying ChassisTypes in Win32_SystemEnclosure.  Unfortunately, ChassisTypes is an array value; the WQL that is used in the task sequence is limited to single values.

To work with this, add the following vbscript to a Run Command Line task.  It creates a custom Task Sequence variable that can then be used to dynamically limit certain tasks to “desktops” and others to “laptops”.

' NAME: SMSTSEnvChassisType.vbs
' AUTHOR: Nick Moseley, SCCM Administrator
' DATE  : 4/24/2009
' COMMENT: Script creates custom TS variable that can be used to distinguish
' between a desktop and a laptop for dynamically selecting which tasks
' to run in the sequence. Note that the echo statements are logged in SMSTS.log
Dim oTaskSequence, oWMI, colChassis, sChassisType, oChassis
Set oTaskSequence = CreateObject ("Microsoft.SMS.TSEnvironment")
Set oWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2")
Set colChassis = oWMI.ExecQuery("Select * from Win32_SystemEnclosure")
For Each oChassis in colChassis
For  Each sChassisType in oChassis.ChassisTypes
  Select Case sChassisType
      Case 8
                Wscript.Echo "Chassis Type: Portable"
                oTaskSequence ("OSDImageType") = "laptop"
            Case 9
                Wscript.Echo "Chassis Type: Laptop"
                oTaskSequence ("OSDImageType") = "laptop"
            Case 10
                Wscript.Echo "Chassis Type: Notebook"
                oTaskSequence ("OSDImageType") = "laptop"
            Case 12
                Wscript.Echo "Chassis Type: Docking Station"
                oTaskSequence ("OSDImageType") = "laptop"
            Case Else
                Wscript.Echo "Chassis Type: Unknown"
                oTaskSequence ("OSDImageType") = "desktop"
  End Select

Script to Prompt for System Name in SCCM OSD

Posted on Updated on

When doing a baremetal image in SCCM OSD, the task sequences will generate a random name for the system. To define a specific name the system is to receive, use the following VBScript.  It will prompt the end-operator to input a name and then it will set the TS variable “OSDComputerName”.

Add the script to the TS by adding a Run Command Line task after Partition Disk and before Apply Operating System.


' NAME: PromptForSystemName.vbs
' AUTHOR: Nick Moseley
' DATE  : 6/1/2009
' COMMENT: This script will detect if the current assigned value for the computer name
' begins with MININT, indicating that this image is bare metal image.  It then prompts
' the end-user to enter a new computer name.
' VERSION : 1.1
' 1.0 (12/08/2008)- Intial script to check if the computer name begins with
'  "minint", which indicates the system was booted with CD or PXE.
' 1.1 (06/01/2009)- Added check if the computer name equals "minwinpc",
'  which indicates the system was booted with USB key

Dim sNewComputerName, oTaskSequence, sTSMachineName, bPromptName
Set oTaskSequence = CreateObject ("Microsoft.SMS.TSEnvironment")

' Get the name the computer is set to receive and truncate to first 6 letters
sTSMachineName = lcase(oTaskSequence("_SMSTSMachineName"))
If left(sTSMachineName,6) = "minint" Then
   bPromptName = True
ElseIf sTSMachineName = "minwinpc" Then
   bPromptName = True
   bPromptName = False
End If

' Note: The wscript.echo commands are logged in SMSTS.log for troubleshooting.  They are not displayed to the end user.
If bPromptName = True Then
   wscript.echo "Detected that the computer name is scheduled to receive a random value.  Prompting user to input a standard name."
   sNewComputerName = InputBox ("Please enter a standard computer name to continue.", "Computer Name", , 30,30)
   oTaskSequence("OSDComputerName") = UCase(sNewComputerName)
   wscript.echo "Set Task Sequence variable OSDComputerName to: " & sNewComputerName
   wscript.echo "Computer set to receive a standard name, continuing as is."
End If

Blocked Executables

Posted on Updated on

When distributing software through SMS/SCCM, occasionally the advertisement will reach the time limit threshold of the package/program, which will generate an error for the advertisement.  There are two things that likely have caused this: first and foremost, the program truly didn’t finish installing in time.  Simply readjust the run time value in the program. 

Secondly, the execuble could be getting “blocked” and requesting the end-user to accept the Open File Security Warning.  If the program (for the package) is configured to be hidden and/or does not allow user interaction, then the user will never see such prompt (which is a good thing I might add).  Heck, even in your troubleshooting, you will never see the prompt (side note: if you are troubleshooting, then be sure to configure the program to run normal and allow user’s to interact with the program).  If you can see it, it would look like this below:


This is caused by the Windows Attachment Manager marking the file with a property that helps in the system security.  The quirky thing is that, if the executable is indeed blocked, not ever system is affected.  Though there are several variables that can contribute to the issue, the quick fix is to (in the original package source) right-click on the .exe, select Properties, click “Unblock”, then click “OK”


Going back to how this impacts SCCM software distribution, unblocking the .exe does little to change the actual file itself.  So if all you do is update your distribution points, then readvertise the distribution, the clients will not download the modified file…so the blocking will still occur.  It is easiest to simply delete the package and recreate it.  Keep in mind, if you did already modify the original package source files, then you can reuse the same source file location.

Scripting Windows Live 2009/2011

Posted on Updated on

The Windows Live Essentials suite comes bundled with various applications, such as Messenger, Mail, Writer, Toolbar, etc etc.  No suppose you need to script this install.  Well, it’s easy!  That is, it’s easy if you just want intall ALL of the applications.  But what if you only need to install Messenger?  Or Writer?  Or both?  Unfortunately, Microsoft hadn’t published anything publically yet on how to achieve this, so I had to contact PSS to get the information I needed.  Below are instructions for solely installing Messenger, but I’ll list the switches for the other applications.

  1. Download the WLSetup
  2. Install Messenger only by creating a scripted install that triggers WLSetup.exe /AppSelect:Messenger

Additional switches are as follows:

  • AppSelect:[ProductID] or ![ProductID]
  • log:log_location
  • NOToolbarCEIP (to not opt into Toolbar CEIP)
  • NOhomepage (to not set home page defaults)
  • Nolaunch (blocks all applications from running automatically after your installation is complete)
  • NOMU (to opt the computer into Microsoft Update)
  • nosearch (to not set search defaults)
  • q (for a silent/unattended install)