First published on MSDN on Oct 18, 2015
Standalone media is a very useful option for building bare metal systems in areas with limited or no network access. Standalone media is also a great failsafe solution to allow builds to continue when problems exist that prevent contact with the ConfigMgr server or related systems.
When using standalone media in scenarios where zero network connectivity exists the concepts in this article won’t apply. If standalone media IS being used in areas of limited or even full but slow network connectivity, read on.
One of the challenges of using standalone media is the possibility that a particular media may become outdated resulting in builds that are immediately out of date. Ensuring media remains up to date often is left to the ConfigMgr administrative team to coordinate. But even with the best efforts such processes are often inadequate. Instead, what if there were a process available to engineer the task sequence itself to make sure it is up to date before proceeding with imaging? It is actually really easy to configure such a scenario and ensure out of date standalone media will not run. A further benefit of such an approach would be to offload the work of maintaining media to the users of the standalone media.
The process demonstrated in this article makes use of some task sequence tweaks and also Orchestrator. Please note that the example provided here is just that – an example. Further refinement will be necessary for use in a production environment. Also, the example shown is designed for a task sequence delivered through standalone media. This example could be extended to other scenarios as well. On to the example.
The example makes use of a two network shares, task sequence customizations and a custom Orchestrator runbook.
Network Shares
Two separate shares are used in this example.
The first share will host a text file where the expected current version of the task sequence will be published. Each time the standalone task sequence is updated administrators will need to version up the text file in the share to match the version reflected in the task sequence. The task sequence will be shown shortly.
The second share will host the most recently built standalone media iso file. This will be the share location where users of standalone media will be able to obtain the latest iso build for use in updating their media.
Task Sequence
A standard, wizard generated, task sequence was created and then modified to add a Version Checking section, as shown.
Just three easy steps.
Set Task Sequence Version to Variable
This step defines the specific version of this particular task sequence and stores it as a variable in the task sequencing environment. In this case the assigned version is 15. Each time the task sequence is updated and a new version released the version number within the task sequence will be incremented. Not only does this facilitate version control but it also helps get in the habit of treating a task sequence like code and adopting all of the methodical change processes that are used when introducing new code to an environment.
Connect to Network Folder
Next the task sequence maps a network drive to the share hosting the master version information.
Retrieve Current Task Sequence Version
The production task sequence version will be stored in the CurrentTSversion.txt file seen earlier. This step will retrieve the version number from that file and publish it as a variable in the task sequencing environment.
Note that in this example a run command line step is used which calls PowerShell directly and passes the script, all in the command line. Typically, a package and Run PowerShell Script step might be used but for something this simple the Run Command Line step is easier and self-contained.
powershell.exe -executionpolicy bypass -command "& {$tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment; $tsenv.Value('CurrentTSVersion') = get-content z:\CurrentTSversion.txt}"
Finally, on the Imaging Section group, logic is added that will compare the TSVersion variable, hard coded at the beginning of the Task Sequence, and the CurrentTSVersion variable, dynamically created after reading the txt file.
In order for imaging to proceed the value contained in both variables must match, indicating that the task sequence being used is, in fact, the current one.
The result? No more out of date imaging!
But there is a second part. A process that will detect a version change and automatically generate a new iso file that technicians will use to update their media. That part is handled with a very simple Orchestrator runbook. As mentioned earlier, the runbook is simply an example. More elegant methods could be brought to bear in production.
For the example the Orchestrator runbook will execute every hour using a Monitor Date/Time activity, shown here with the label Execute runbook hourly.
The next action compares the filename of the current standalone ISO file against the version of the task sequence stored in the CurrentTSVersion file. The ISO is expected to have the version number embedded as part of the filename so if there is not a match then something is wrong and the ISO needs to be regenerated. The script hard codes the server and location of the ISO and TXT files being used for comparison. While this works fine it may be more flexible to leverage variables in the Orchestrator environment and pass them here to allow for moving these files, if ever required, without requiring direct changes to the script.
$PSE = Powershell {
$script={
$Match="No"
$CurrentTSVersion=get-content C:\TSVersion\CurrentTSVersion.txt
$LastISOGeneratedFile=get-childitem c:\standalone
$LastISOGeneratedFileName=$LastISOGeneratedFile.BaseName
If ($LastISOGeneratedFileName.Contains("$CurrentTSVersion"))
{
$Match="Yes"
}
$Match}
invoke-command -computer labsrvcmcas -scriptblock $script
}
This step doesn’t make any decisions about the Match value but simply adds it to the databus by specifying to do so on the Published Data tab. In addition, the script detected the published current version of the Task Sequence and publishes that to the databus as well.
With the data published to the database the runbook connector is leveraged to decide whether to proceed. More robust logic may be useful at this stage to make sure specific requirements are better handled. For the example the logic simply checks the match variable to see if the ISO file has the currect version number located in the filename text.
$PSE = Powershell {
$script={
$file=get-item C:\TSVersion\CurrentTSVersion.txt
$filelastwritetime=$file.lastwritetime
$TimeDiff = new-timespan -Start $filelastwritetime -end (get-date)
$TimeDiff=$TimeDiff.hours}
invoke-command -computer labsrvcmcas -scriptblock $script
}
If the versions are found not to match, PowerShell is used to trigger the creation of the new ISO which will be stored in the standalone folder.
$PSE = Powershell {
import-module($Env:SMS_ADMIN_UI_PATH.Substring(0,$Env:SMS_ADMIN_UI_PATH.Length-5) + '\ConfigurationManager.psd1')
CD CAS:
$NewISOFileName = "Standalone" + "\`d.T.~Ed/{ADA9AA9E-F470-4340-A7E9-E9A25AD3DA03}.CurrentVersion\`d.T.~Ed/" + ".iso"
Remove-Item \\labsrvcmcas\\standalone\ *
New-CMTaskSequenceMedia -StandAloneMediaOption -MediaInputType CDDVD -MediaPath "\\labsrvcmcas\standalone\$NewISOFileName" -ProtectPassword 0 -TaskSequenceId "CAS00065" -TaskSequenceDistributionPointServerName "labsrvcmps1.contoso.com"
}
Another easy Orchestrator step that could be added would be to send email notification to interested parties when a new ISO is available.