The Deployment Guys

Helping to deploy your world automagically...

Deprecation of the OSVersion Property and What to Do About It

Deprecation of the OSVersion Property and What to Do About It

  • Comments 3
  • Likes

The OSVersion variable is populated with a short string representing the version of the operating system (e.g. XP, Vista, Win7Client, 2008, etc.).  With MDT 2012, you may have noticed that when you deploy Window 8 that the value of the OSVersion variable gets set to “Other” instead of something like “Win8”.  This is because the MDT team has deprecated the OSVersion property.  The logic that set this property has not been updated for Windows 8 and will no longer be updated.  The team decided that using these string values in script logic leads to hidden bugs and unexpected behavior as new OS versions are released.  For example, code testing for a client OS that is Windows Vista or higher would require something like this using OSVersion:

If oEnvironment.Item("OSVersion") = "Vista" Or oEnvironment.Item("OSVersion") = "Win7Client" Then…

This would work until Windows 8 was released.  Then this would have to be updated with another OR with the Windows 8 value.  They now recommend using a variable called OSCurrentVersion which has a value of the OS major and minor version (e.g. 6.1 for Windows 7).  So the equivalent code using OSCurrentVersion would look like this and would continue to work as new operating systems are released:

If CSng(oEnvironment.Item("OSCurrentVersion")) > 6.0 And UCase(oEnvironment.Item("IsServerOS") = "FALSE" Then...

While I wholeheartedly agree with this reasoning, there is one instance where I like an easily recognized string for the OS version.  This is composite custom property called ModelOSArchAlias that I defined in my Model Alias post. which combines the ModelAlias, OSVersion, and Architecture properties.  These values are used to create Make and Model entries in the MDT database.  Using OSCurrentVersion instead of OSVersion would lead to ModelOSArchAlias values like ThinkPadT420_6.1_X64 instead of the more easily readable ThinkPadT420_Win7Client_X64.  Also, since Windows team seems to have developed an aversion to increasing the major version of Windows, I see it becoming easy to confuse which version you are referencing with an OSCurrentVersion of 6.0, 6.1, 6.2, or 6.3 (Windows Vista, 7, 8, and 8.1 respectively).

So to make it possible to use a short string representing the version of the operating system that is current, I’ve created a function called GetOSVersionTag that is essentially a copy of the ZTIGather.wsf code that sets OSVersion with some improvements and updated to set proper values for Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2.  I have placed this function in a class library script that I have been building up over the years called MDTLibHelperClasses.vbs.  This script is conceptually similar to ZTIUtility.vbs.  It can be referenced similarly in other MDT scripts and using the technique from my last post it can also be used as a User Exit script.  As I create new general purpose functions going forward, I will place them in future versions of this library as appropriate.

To use this function to create a custom variable called OSVersionTag and use that in ModelOSArchAlias, add MDTLibHelperClasses.vbs (and MDTExitInclude.vbs and ModelAliasExit.vbs from the two previous posts referenced earlier) to the Scripts folder of your Deployment Share or Configuration Manager MDT Files package and add the following to CustomSetting.ini (used during Gather in the newly deployed OS):

[Settings]
Priority=IncludeExitScripts, ModelAliasVars, Default
Properties=ExitScripts(*), OSVersionTag, ModelAlias, ModelOSArchAlias

[IncludeExitScripts]
UserExit=MDTExitInclude.vbs
ExitScripts001=#Include("MDTLibHelperClasses.vbs")#
ExitScripts002=#Include("ModelAliasExit.vbs")#

[ModelAliasVars]
OSVersionTag=#oHelperFunctions.GetOSVersionTag#
ModelAlias=#SetModelAlias()#
ModelOSArchAlias=%ModelAlias%_%OSVersionTag%_%Architecture%

 

 

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of included script samples are subject to the terms specified in the Terms of Use.

This post was contributed by Michael Murgolo, a Senior Consultant with Microsoft Services - U.S. East Region

Attachment: MDTLibHelperClasses.zip
  • Isn't this string-based comparison going to run into the same trouble that IE scripts hit when they went from IE9 to IE10?  As an alphabetic comparison, "9.0" > "10.0".

  • Hi Aaron,

    In this line:

    If oEnvironment.Item("OSCurrentVersion") > 6.0 And UCase(oEnvironment.Item("IsServerOS") = "FALSE" Then...

    I believe VBScript should coerce the string returned by oEnvironment.Item("OSCurrentVersion") to a floating point number since 6.0 is not specified as a string (no quotes).  However, you are correct that it would better to explicitly use CSng or CDbl to convert the string first.

    Michael Murgolo

  • It turns out I was wrong about coercion in this case.  Here is the behavior with VBScript comparison operators (msdn.microsoft.com/.../9hck4s70(v=vs.84).aspx).  So it is important to use CSng or CDbl to convert the string to a numeric type in this case.  I have updated the sample line in the post accordingly.

    Michael Murgolo

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment