Windows 10 Features that require UEFI

Device Integrity

Secure Boot

Early Launch Anti-Malware

Measured Boot

Virtualization Based Security

Device Guard

Migrating from Windows 7

Figure 1. Default Windows 10 Start Layout

In previous editions of Windows (Windows 10 RTM and Windows 8.1) it was possible to create customized Start layouts for an organization. However, there were only two options available to control these start layout customizations:

• Locked Down Start Layout – The start layout was customized to meet an organizations requirement but it was entirely locked down and could not be customized by users
• Customizable Start Layout – The start layout was customized to meet an organizations requirement but there was nothing to prevent the user from removing all of the organizations customizations,  

Windows 10 version 1511 has introduced a new feature which makes it possible for an organization to customize the start layout by locking down individual groups within the Start layout. This allows an organization to customize their start layout and ensure that their corporate applications are always present on Start while allowing the end user the freedom to customize the start layout with their own applications.

In this topic:

• Exporting a Start layout
• Applying a Start layout
• Updating a Start layout
• Partially locking down groups in the Start Layout

Exporting a Start layout

The simplest way to create customized Start layouts to apply to an organization is to manually create a sample layout on a test machine and then export that layout. The exported Start layout can then be deployed to all machines in the organization. To prepare a Start layout for export, you simply customize the Start layout on a test computer.

Prepare a test computer

1. Set up a test computer on which to customize the Start screen. Your test computer should have the either Windows 10 Enterprise or Windows 10 Education. Install all the applications and services that the Start screen should display.
2. Create a new user account that you will use to customize the Start screen layout.
3. Sign in to your test computer with the user account that you created.
4. Customize the Start screen as you want users to see it by using the following techniques:

Customize the Start Layout

• Pin apps to the Start screen. From the Start screen, type the name of the app. When the app appears in the search results, right-click the app, and then click Pin to Start.

To view all apps, click All apps in the bottom-left corner of the Start screen. Right-click any app, and pin or unpin it from the Start screen.

• Unpin apps that you don’t want to display. To unpin an app, right-click the app, and then click Unpin from Start.
• Drag tiles on the Start screen to reorder or group apps.
• Resize tiles. To resize tiles, right-click the tile and then click Resize.
• Create your own app groups. Drag the apps to an empty area. To name a group, click above the group of tiles and then type the name in the Name group field that appears above the group.

Figure 2. Customized Windows 10 Start Layout

Export the Start Layout

When you have the Start screen layout that you want your users to see, use the Export-StartLayout cmdlet in Windows PowerShell to export the Start screen to an .xml file.

1. From Start, open Windows PowerShell.
2. At the Windows PowerShell command prompt, enter the following command:

Export-StartLayout –path <path><file name>.xml

Figure 3. Export-StartLayout cmdlet

In the previous command, -path is a required parameter that specifies the path and file name for the export file. You can specify a local path or a UNC path (for example, \\FileServer01\StartLayouts\StartLayoutMarketing.xml). The file must be accessible on the local computer when a user signs in (the user must have Read-only access). If the file is not available, the Start screen layout is not deployed during that session, and the user can make changes to the Start screen.

If you plan to deploy a GPO that customizes Start screen layouts for domain users, store the .xml file in shared network storage that all of the users can access.

Use a file name of your choice - for example, StartLayoutMarketing.xml. Include the .xml file name extension. The Export-StartLayout cmdlet does not append the file name extension, and the policy settings require the extension.

Applying a Start layout

Once you have an exported Start Layout you can use the XML file to apply this start layout to your entire organization using PowerShell or Group Policy.

PowerShell

When you have the Start screen layout exported, use the Import-StartLayout cmdlet in Windows PowerShell to manually import the .xml file into the system.

1. From Start, open Windows PowerShell.
2. At the Windows PowerShell command prompt, enter the following command:

Import-StartLayout –LayoutPath <path><file name>.xml –MountPath %systemdrive%

Figure 4. Import-StartLayout cmdlet

Important 

Applying a Start Layout through the Import-StartLayout cmdlet will not enforce the layout and users will have an option to perform changes. This will only apply to new user profiles created in the machine after applying the custom Start Layout.

Group Policy

To apply the Start layout to users in a domain, use the Group Policy Management Console (GPMC) to configure a domain-based Group Policy Object (GPO) that sets Start Layout policy settings in the Start Menu and Taskbar administrative template for users in a domain.

The GPO applies the Start layout at the next user sign-in. Each time the user signs in, the timestamp of the .xml file with the Start layout is checked and if a newer version of the file is available, the settings in the latest version of the file are applied.

The GPO can be configured from any computer on which the necessary ADMX and ADML files (StartMenu.admx and StartMenu.adml) for Windows 10 are installed.

The .xml file with the Start layout must be located on shared network storage that is available to the users’ computers when they sign in and the users must have Read-only access to the file. If the file is not available at sign-in, the Start screen is not customized during the session, and the user can make changes to the Start screen.

1. On a Domain Controller, open the Group Policy Management Console (gpmc.msc).
2. In the Group Policy Management Console, browse to Group Policy Management > Forest: <forest name> > Domains > <domain name> > Group Policy Objects.
3. Right-click on Group Policy Objects and select New.
4. In the New GPO dialog box, provide a Name then click OK.
5. Right-click on the GPO created from the previous step then select Edit.
6. Go to User Configuration or Computer Configuration > Policies > Administrative Templates >Start Menu and Taskbar.
7. Right-click Start Layout in the right pane, and click Edit. This opens the Start Layout policy settings.
8. Enter the following settings, and then click OK:
   1. Select Enabled.
   2. Under Options, specify the path to the .xml file that contains the Start layout. For example, type C:\Users\Test01\StartScreen.xml or \\ShareName\StartScreen.xml.
   3. Optionally, enter a comment to identify the Start layout.

Figure 5. Start Layout Group Policy Setting

Important 

By default, applying Start Layout customizations via GPO will enforce the layout and prevent users from performing changes. To allow users to modify the Start Layout, go to the Partial Lockdown section.

Provisioning Packages

Use the Imaging and Configuration Designer (ICD) tool included in the Windows Assessment and Deployment Kit (ADK) for Windows 10 to create a provisioning package that applies a customized Start layout. Install the ADK.

1. Open ICD (by default, %windir%\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Imaging and Configuration Designer\x86\ICD.exe).
2. Choose New provisioning package.
3. Name your project, and click Next.
4. Choose Common to all Windows editions and click Next.
5. On New project, click Finish. The workspace for your package opens.
6. Expand Runtime settings > Start, and click StartLayout.
7. Specify the path and file name of the Start layout .xml that you created with the Export-StartLayout cmdlet.
8. On the File menu, select Save.
9. On the Export menu, select Provisioning package.
10.  Change Owner to IT Admin, which will set the precedence of this provisioning package higher than provisioning packages applied to this device from other sources, and then select Next.
11.  Optional. In the Provisioning package security window, you can choose to encrypt the package and enable package signing.
    1. Enable package encryption - If you select this option, an auto-generated password will be shown on the screen.
    2. Enable package signing - If you select this option, you must select a valid certificate to use for signing the package. You can specify the certificate by clicking Select... and choosing the certificate you want to use to sign the package.
12. Click Next to specify the output location where you want the provisioning package to go when it's built. By default, Windows Imaging and Configuration Designer (ICD) uses the project folder as the output location.

1. Optionally, you can click Browse to change the default output location.

• Click Next.
• Click Build to start building the package. The provisioning package doesn't take long to build. The project information is displayed in the build page and the progress bar indicates the build status.  If you need to cancel the build, click Cancel. This cancels the current build process, closes the wizard, and takes you back to the Customizations Page.
• If your build fails, an error message will show up that includes a link to the project folder. You can scan the logs to determine what caused the error. Once you fix the issue, try building the package again.

If your build is successful, the name of the provisioning package, output directory, and project directory will be shown.

• If you choose, you can build the provisioning package again and pick a different path for the output package. To do this, click Back to change the output package name and path, and then click Next to start another build.
• If you are done, click Finish to close the wizard and go back to the Customizations Page.
  

16.   Copy the provisioning package to the target device.

17.   Double-click the ppkg file and allow it to install.

Important

By default, applying Start Layout customizations via Provisioning Packages will enforce the layout and prevent users from performing changes. To allow users to modify the Start Layout, go to the Partial Lockdown section.

Updating a Start layout

General

After you use Group Policy to apply a customized Start layout on a computer or in a domain, you can update the layout simply by replacing the .xml file that is specified in the Start Layout policy settings with a file with a newer timestamp.

1. Customize the Start screen on your test computer the way that you want it to look for users.
2. Run the Export-StartLayout cmdlet, with the following format, to export the new Start screen layout to an .xml file that overwrites the original file:

Export-StartLayout –path <path><file name>.xml

Partial Lockdown

By default, applying a custom Start Layout via Group Policy enforces and locks down the Start Layout which prohibits users in making any modifications. For Enterprises that would like to provide users the ability to personalize or modify the Start Layout while only partially locking down certain groups they can update the custom Start Layout xml file to support this capability. This feature is only available in Windows 10 version 1511.

1. Open the exported Start Layout .xml file
2. Locate the <DefaultLayoutOverride> section and add a parameter as detailed below.

<DefaultLayoutOverride LayoutCustomizationRestrictionType=”OnlySpecifiedGroups”>

 Figure 6. Partial Lockdown Parameter

3.  Save the update Start Layout .xml file and apply via Group Policy or Provisioning Packages.

Figure 7. Start Layout applied with Partial Lockdown setting

Important 

Applying a Start Layout using the "OnlySpecifiedGroups" parameter using Group Policy or provisioning packs will only lock the groups specified in the Start Layout xml. file All other groups in the Start Layout can be controlled by the user.

Frequently Asked Questions

Q) Is it possible to programmatically modify the start screen through an API.

A) No. There is no API that allows programmatic access to the Start Layout. The Start Layout XML could be programmatically edited to automatically customize the Start Layout.

Additional Resources

• TechNet - Start Screen Cmdlets in PowerShell
• TechNet - Customize and Export Start Layout
• TechNet - Customize Windows 10 Start with Group Policy 
  

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 Mark Hooks and Marvin Quinzon, both architects within Microsoft Services.

I recently has a requirement for a UI that could not be met with the UDI Wizard.  So I created custom HTML Applications (HTA) for this instead.  You can find various articles on the web that describe using ServiceUI.exe with other user interfaces like HTML Applications like this one: https://blogs.technet.com/b/cameronk/archive/2011/01/25/can-i-use-serviceui-exe-to-launch-other-programs-besides-the-udi-setup-wizard.aspx.  But to use it correctly, you have to make sure to pick the correct process for ServiceUI to use to find the correct desktop on which it will display the custom UI.  There are also other things that UDIWizard.wsf takes care of in its code, like dismissing the task sequence progress UI before displaying the custom UI.

So to get the benefits of using the code in UDIWizard.wsf with any other UI executable, I basically took the code from UDIWizard.wsf, removed all the UDI Wizard handling code, and add the bits to launch another executable.  The new script, MDTRunWithServiceUI.wsf, should be added to the Scripts folder of the ConfigMgr MDT Toolkit package.  It should be run with a Run Command Line step and has a command line syntax as show in this example:

cscript "%DeployRoot%\Scripts\MDTRunWithServiceUI.wsf" /UIExePath:"%SystemRoot%\System32\mshta.exe" /UIExeParam:"%DeployRoot%\Scripts\MyHTA.hta"

where /UIExePath is the path of the executable to launch and /UIExeParam is the optional command line parameter to pass to the executable.  (If you look at the script header you will notice an additional command line switch of /UIExeTitle.  I some instances when launching our task sequence from Software Center, the HTA would pop up behind Software Center instead on top of it.  The code run by this switch was my attempt to launch a VBScript on the same desktop to attempt to “activate” the window and make it topmost.  As you can see from the notes in the header I have not be able to get this to work.  If any of you do figure this out, post back a comment on how you did it).

MDTRunWithServiceUI.wsf is provided below.

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.

MDTRunWithServiceUI.zip

This behavior may not be desirable in all cases.  For example, for one deployment I was setting a custom variable during Gather called ComputerRecordExists that would be True if an MDT database record existed for the computer and False if it did not.  In this task sequence, if ComputerRecordExists was found to be False, then a stored procedure was run against the scheduling database.  If the computer was scheduled for deployment, the procedure would kick off a server side process to create the database record.  I then needed to run Gather a second time and reset ComputerRecordExists (and a few other variables) based on if a record now existed.  However, by default the second Gather would not change the values because they had already been set.  There are a few ways this could be handled with existing task sequence steps or configuration files but none were particularly elegant to me.

First, I could have added static Set Task Sequence Variable steps to clear the values of all the variables in questions.  I wasn’t happy with having to have step external to Gather for this.  Second, variables can be added to ZTIGather.xml and variables in there can have their overwrite property changed.  However, doing this creates a persistent change for that Deployment Share/Toolkit package.  Also, changes to ZTIGather.xml may also be overwritten when upgrading versions of MDT.  What I really wanted was just to have a directive in CustomSettings.ini that would make the specified variables over-writable for that run of Gather.

So I took a deep dive into ZTIGather.wsf and ZTIUtility.vbs and managed to accomplish just this.  The route to getting there is kind of complicated.  If you’re not interested in the internals of these scripts and the code I used to do this, just jump down to the implementation section below.  For those who are interested, here we go.

Script Internals

Starting with BDD 2007, the deployment scripts in MDT were written as VBScripts in the Windows Script File (WSF) format used by the Windows Script Host.  The original ones (BDD 2007 – MDT 2008) used a main ZTIProcess function with the other supporting functions in global (or script) scope.  (If you are not familiar with the concept of scope in VBScript, there is an overview here: https://msdn.microsoft.com/en-us/subscriptions/t7zd6etz(v=vs.84).aspx.)

Starting with MDT 2010 the WSF scripts were changed to implement almost all the code in a VBScript Class. The Class name must match script file name. This was done to better facilitate unit testing. Because of this change, the procedures/variables in the scripts are no longer available in global scope.  Why is not having the procedures/variables available in global scope an issue?  Because you may want to do something like calling functions or access objects in the ZTIGather.wsf class in CustomSetting.iniand this will not work the way these script are written.

In the ZTIGather.wsf class, the list of properties for which overwrite="true" are stored in a Dictionary object called dicOverwrite.  Because this object is not available in the global scope we cannot simply add a line like AddToOverwiteDic=#dicOverwrite.Add("ComputerRecordExists", "")# to CustomSettings.inito add a property to the list

Fortunately, while digging though ZTIUtility.vbs I found the place where the MDT Team hooks in to run their unit test code.  (You learn something new every day.)  This can be leveraged to run custom script code to solve this problem.  To understand this, I have to give you a little insight into what I found out about what happens when an MDT 2010-style WSF script is run. The first thing the script does is call RunNewInstance. This is a global function in ZTIUtility.vbs.  RunNewInstance calls oUtility.RunNewInstanceEx. This function actually creates the instance of the script Class as the variable oScriptClass in the scope of this function.  After that it looks to see if the /TestHook command line argument was specified.  If it was, the VBScript file specified with the /TestHook argument is read and executed in the same local scope.  Finally the Main function in the class is run in the same scope.  Because this TestHook file is executed in the same scope as the oScriptClassobject, the code in the TestHook file can then make it available in the global scope using these lines of VBScript:

ExecuteGlobal "Dim oScriptClassGlobal"
Set oScriptClassGlobal = oScriptClass

These lines dimension the oScriptClassGlobal variable in the global scope and then set it equal to the oScriptClass object. Now oScriptClassGlobalcan be used to access the properties and method in the script Class instance in the global scope.

The TestHook script that I created, MDTTestHookGatherOverwriteProperties.vbs, takes this a little further.  When RunNewInstanceEx locally executes the script, the code above is run and a global variable called bTestHookExecuteLocal is set to True indicate that this first execution happened.  Then the TestHook script reads the contents of itself and executes it in the global scope to make a function called AddOverwriteProperties available globally.  The global variable bTestHookExecuteLocal is checked to make sure the second global execution does not redo the tasks that only needed to be done in the first local execution.  The AddOverwriteProperties function is the function that will be used to dynamically make variables over-writable in CustomSettings.ini.

Implementing the Solution

Fortunately, implementing this is simpler than understanding how it works.  First, add MDTTestHookGatherOverwriteProperties.vbs to Scripts folder in the LTI Deployment Share or ConfigMgr MDT Toolkit package.

Because of the way the TestHook works, you cannot use the MDT Gather task sequence step since this process requires passing the /TestHook argument on the ZTIGather.wsf command line.  So for any Gather where you want to use this technique, you will need to use a Run Command Line step instead.  The command line for this step should be

cscript "%DeployRoot%\Scripts\ZTIGather.wsf" /inifile:CustomSettings.ini /TestHook:"%DeployRoot%\Scripts\MDTTestHookGatherOverwriteProperties.vbs"

You would then change CustomSettings.ini to add the highlighted items below:

[Settings]
Priority=TestHookSubsection, TestCustomProperty1, TestCustomProperty2, Default
Properties=AddOverwriteProperties, MyCustomProperty

[TestHookSubsection]
Subsection=TestHookLoaded-#ConvertBooleanToString(oUtility.Arguments.Exists("TestHook"))#

[TestHookLoaded-True]
AddOverwriteProperties=#AddOverwriteProperties("MyCustomProperty")#

[TestCustomProperty1]
MyCustomProperty=Foo

[TestCustomProperty2]
MyCustomProperty=Bar

[Default]
OSInstall=Y

The AddOverwriteProperties function takes as a parameter a string that is a comma separated list of properties to be added to the list of properties that can be overwritten.  This should work for standard and custom properties.  Caution should be take when changing the behavior of standard MDT properties as the MDT scripts may not expect these to change.  Test thoroughly before doing that.

Without using MDTTestHookGatherOverwriteProperties.vbs as the TestHook, the custom property MyCustomProperty in the example would retain the value of Foo even when the TestCustomProperty2 section is processed.  With this TestHook script in place, the value will change to Bar when the TestCustomProperty2 section is processed.

MDTTestHookGatherOverwriteProperties.vbs  is provided below.

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.

MDTTestHookGatherOverwriteProperties.zip

I wanted something that would work like a database section in CustomSettings.ini but allow modifications of the database.  So I took the code in ZTIDataAccess.vbs (the MDT script that actually does the work of the database queries for ZTIGather.wsf) and created a new script, MDTDataModify.vbs, that allows you to add sections to CustomSettings.ini that are very similar to the database query section but do database modify operations instead.

To use this script, the account used to access the database (MDT user account or ConfigMgr Network Access Account) must have at least db_datareader and db_datawriter on the MDT database.

Since this script contains a VBScript Class it must be loaded during in CustomSettings.ini using MDTExitInclude.vbs from this previous post.

[Settings]
Priority=IncludeExitScripts, Default
Properties=ExitScripts

[IncludeExitScripts]
UserExit=MDTExitInclude.vbs
ExitScripts=#IncludeFiles("MDTDataModify.vbs")#

This script allow 3 different types of table operations: Update, Insert, and Delete.  Update allows you to modify an existing record.  Insert allows you to add a new record.  Delete allows you to delete a record.

The CustomSettings.ini sections that are used with MDTDataModify.vbs are very similar to the standard database query sections supported by ZTIGather.wsf.  The following properties are used:

All the properties except the new Statement and WriteParameters properties work the same way as standard MDT database query section.

These sections also support variable remapping as a described in this post: https://blogs.technet.com/b/deploymentguys/archive/2013/08/12/remapping-variables-in-mdt-database-queries.aspx.

To have a database modify section run in CustomSetting.ini, you DO NOT add it to the Priority line directly.  If you do ZTIGather.wsf would treat it as standard database query section.  Instead, you need to use the ModifySQL function that is included in MDTDataModify.vbs to run the section.  Here are a few examples.

Database Update

In this example, the computer name (OSDComputerName) is generated based on the string “ws” and the first 10 characters of the serial number.  Since this name is generated during the deployment it would be nice to have this value written back to the computer record for reference later.  The following sample CustomSettings.ini will update an existing computer record:

[Settings]
Priority=Common, IncludeExitScripts, RunDBChanges
Properties=ExitScripts(*), Type, ID, ComputerID, DBChanges(*), MDTSQLServer, MDTDatabase, MDTNetlib, MDTSQLShare

[Common]
MDTSQLServer=SQLServer1
MDTDatabase=MDT
MDTNetlib=DBNMPNTW
MDTSQLShare=SQLShare$
OSDComputerName=ws#Right("%SerialNumber%", 10)#

[IncludeExitScripts]
; Load all user exit scripts
UserExit=MDTExitInclude.vbs
ExitScripts001=#Include("MDTDataModify.vbs")#

[RunDBChanges]
DBChanges001=#ModifySQL("UpdateCSettings")#

[UpdateCSettings]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Statement=Update
WriteParameters=OSDComputerName

Database Insert

In this example I show how you can create the record for a computer by simply running a Gather step will the following sample CustomSetting.ini.  This is useful if you are unboxing a new computer and don’t want to depend on manually entering a record in the database by hand (which can be error prone).  For example, you could create MDT or ConfigMgr task sequence media with a two step task sequence (Use Toolkit Package and Gather steps only) and boot the new machine with this media.  The following sample CustomSettings.ini will insert a new computer record by first creating the ComputerIdentity table entry with the hardware variable values and then creating the associated Settings table entry (Type=C and ID that matches the ID of the ComputerIdentity table entry).  The ModifySQL function with return an InsertID value if it creates a record with an identity value.  I remap this to ComputerID to use it as an input to the second Insert section, remapping it to the ID field in the table.

In this sample I add the record with OSInstall set to NO so that a deployment cannot happen until the rest of the values needed for the record are populated.

[Settings]
Priority=Common, IncludeExitScripts, RunDBChanges
Properties=ExitScripts(*), Type, ID, ComputerID, DBChanges(*), MDTSQLServer, MDTDatabase, MDTNetlib, MDTSQLShare

[Common]
MDTSQLServer=SQLServer1
MDTDatabase=MDT
MDTNetlib=DBNMPNTW
MDTSQLShare=SQLShare$
OSInstall=NO
Type=C

[IncludeExitScripts]
; Load all user exit scripts
UserExit=MDTExitInclude.vbs
ExitScripts001=#Include("MDTDataModify.vbs")#

[RunDBChanges]
DBChanges001=#ModifySQL("InsertCIdentity")#
DBChanges002=#ModifySQL("InsertCSettings")#

[InsertCIdentity]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=ComputerIdentity
Statement=Insert
WriteParameters=AssetTag, SerialNumber, MacAddress, UUID, Description
InsertID=ComputerID

[InsertCSettings]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=Settings
Statement=Insert
WriteParameters=Type, ComputerID, OSInstall
ComputerID=ID

Database Delete

In the final example I demonstrate how you can delete the computer record.  If you want to delete the record at the end of a successful deployment (groom records that are no longer needed) you can add a Gather step at the end of the task sequence that uses this sample CustomSettings.ini:

[Settings]
Priority=Common, IncludeExitScripts, RunDBChanges
Properties=ExitScripts(*), Type, ID, ComputerID, DBChanges(*), MDTSQLServer, MDTDatabase, MDTNetlib, MDTSQLShare

[Common]
MDTSQLServer=SQLServer1
MDTDatabase=MDT
MDTNetlib=DBNMPNTW
MDTSQLShare=SQLShare$

[IncludeExitScripts]
; Load all user exit scripts
UserExit=MDTExitInclude.vbs
ExitScripts001=#Include("MDTDataModify.vbs")#

[RunDBChanges]
DBChanges001=#ModifySQL("DeleteCSettings")#

[DeleteCSettings]
SQLServer=%MDTSQLServer%
Database=%MDTDatabase%
Netlib=%MDTNetlib%
SQLShare=%MDTSQLShare%
Table=ComputerIdentity
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Statement=Delete

MDTDataModify.vbs  is provided below.

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.

MDTDataModify.zip

[Settings]
Priority=IncludeExitScripts, Default
Properties=ExitScripts(*)

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

I was recently using this again at another customer and had one of those “duh” moments.  Why didn’t I make the Include function just take a comma separated list of scripts instead of just one?  Then you wouldn’t need multiple lines to load multiple scripts.  So I added a new function to MDTExitInclude.vbs called IncludeFiles that accepts a list of scripts.  This function then calls Include once for each script in the list.  (I did it this way to maintain compatibility with the old method shown above.)  The section can then be simplified to this:

[Settings]
Priority=IncludeExitScripts, Default
Properties=ExitScripts

[IncludeExitScripts]
UserExit=MDTExitInclude.vbs
ExitScripts=#IncludeFiles("MDTLibHelperClasses.vbs,ModelAliasExit.vbs,MDTConfigMgrFunctions.vbs")#

The latest version of MDTExitInclude.vbs is attached below.

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.

MDTExitInclude.zip

While studying up on Windows 10, I came across a technique that has been shown to reduce the time it takes to apply an OS WIM to disk by 20 – 50%*.  That’s a fairly significant savings in time and the implementation of this technique is relatively easy and does not require you to change how you deploy Windows.  Believe it or not, the savings come from adjusting the OS power management settings during a deployment.  While there are multiple ways to implement these power management settings, below I’ve outlined what I consider the most non-intrusive to existing deployment methods. 

Steps:

1. Copy PowerCfg.exe binaries to MDT Files package’s Scripts subfolder

• By default, WinPE runs with the power management scheme set to “Balanced”
• ConfigMgr 2012 R2’s boot images use WinPE v5.0 which is based on the Windows 8.1 OS
• PowerCfg.exe is necessary for changing the power management scheme
• PowerCfg.exe is not included in WinPE
• Create subfolders in the MDT Files package’s Scripts subfolder for each architecture, as shown below:

• From a system running Windows 8.1 (or Server 2012 R2) copy %WINDIR%\System32\PowerCfg.exe to the AMD64 folder in the MDT Files package Scripts folder
• From a system running Windows 8.1 (or Server 2012 R2) copy %WINDIR%\SysWOW64\PowerCfg.exe to the x86 folder in the MDT Files package Scripts folder
• Update distribution points for the MDT Files package (Note: SysWOW64 contains 32 bit files hence we use this folder.)

2. Insert a step early in the task sequence to set the power management scheme to “High performance”

• The GUID for the High performance scheme is “8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c”
• The GUIDs for the default power management schemes in Windows are consistent between Windows versions (Vista and later)
• The first instance of this action is for setting the power scheme during a REFRESH scenario (which starts in the full/old Windows OS).  In this scenario, we want to execute the PowerCfg.exe native binary included in the OS (not the version in the MDT Files package).  The Command line for this instance should be:  “PowerCfg.exe /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c”.  To ensure this action only runs during a REFRESH scenario, the condition on this step should be “_SMSTSInWinPE not equals TRUE”
• The second instance of this action is for setting the power scheme during a NEW COMPUTER scenario (which starts in WinPE).  In this scenario, we want to execute the PowerCfg.exe binary included in the MDT Files package.  The Command line for this instance should be:  “"%DeployRoot%\Scripts\%PROCESSOR_ARCHITECTURE%\PowerCfg.exe" /s 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c”.  To ensure this action only runs during a NEW COMPUTER scenario, the condition on this step should be “_SMSTSInWinPE equals TRUE”
• The example below leverages the MDT-specific variable %DeployRoot% which gets instantiated only after a “Use Toolkit Package”, so be sure to insert the step to change the power scheme after the first “Use Toolkit Package” as shown below:

3. After every “Restart Computer” step within the Preinstall, Install, and Post Installphases, insert another action to reset the power management scheme to “High performance” using the PowerCfg.exe from the MDT Files package.  These 3 phases all run under WinPE which does not persist the power scheme between reboots.  For example:

4. After the first “Restart Computer” step within the State Restorephase, insert another action to reset the power management scheme to “High performance” using PowerCfg.exe from the native (full) Windows OS as shown below.  (NOTE:  Perhaps a better alternative to implementing this step would be to set the power scheme to High performance prior to image capture which would provide the added benefit of using the High performance scheme during PnP enumeration, driver installation, etc.):

5. Finally, set the power management scheme to the scheme you wish for the system to use after the deployment.  In the example below, the GUID for the Balanced power scheme is set.  GUIDs for the built-in power schemes in Windows can be found here.  To set the GUID for any custom scheme, use “PowerCfg.exe –L” to obtain the scheme’s GUID and paste into the Command line for the action: 

Early results are very promising using this technique, we would love to hear if this improved the speed of your deployment via the comments.

*From Windows 10 for PCs and 2 in 1s Manufacturing End-to-End Overview – https://channel9.msdn.com/Events/WinHEC/2015/WDI201

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.

Today's blog post goes behind the scenes to talk about how to prevent installing all published Windows Update's which require multiple reboots to successfully install, during a ZTI deployment Task Sequence. These updates can cause issues as a result of the following behavior; the Task Sequence engine is aware the update requests the initial reboot. Upon boot-up, the Task Sequence engine never initializes and therefore can't be aware that the same update is requiring a second reboot, and thus finally won't make the necessary changes to restart the TS engine again. When the second reboot occurs, during the deployment, the TS will be in an erroneous state, and will cause an error similar to:

"Task Sequence environment not found"

Ideally, these updates should be injected using DISM during the Offline phase of installation, or added during the Build and Capture as the LTI process is not affected by these updates. Either way, a detection and blocking mechanism is needed for your ZTI deployment process.

The following script dynamically query’s the published Microsoft Support page and finds all KB's listed as problematic KB's. Once the list is generated it is up to the administrator to figure out how to block them. This blog post will walk through how to block these updates using MDT as deployment mechanism.

Big thanks to @Dustin Martin for helping in finalizing this script's development.

Below is a standalone version of the script:

$url = "https://support.microsoft.com/kb/2894518"

$i=1 

#Store Source HTML URL

$result = Invoke-WebRequest $url 

#Narrow Source HTML to just Hyperlinks

$elements = $result.AllElements | Where Class -eq "plink" 

#For Each hyperlink

foreach ($link in $elements.innertext)

{

#Find string '/kb/' and get its position

$pos = $link.indexof('/kb/') + 3 

# If '/kb/' not found $pos=-1 +3 = 2

# Not found indicates non KB hyperlink

if ($pos -gt 3)

    {

    #Move the starting position to the start of the KB number and capture all char's to end

    $sOutput = $link.Substring($pos,$link.Length-$pos)

    #Replace '/' and ')' with nothing

    $ExcludeKB = $sOutput.Replace('/','').Replace(')','').Trim()

    #KB Number is stored in $ExcludeKB

    Write-Host $ExcludeKB

    }

$i++ 

} 

Script Functionality

Microsoft has committed to keeping the support page containing the list of problematic updates, up-to date. This support page is located here: https://support.microsoft.com/kb/2894518.

The first function of this script is to go out and store all source code and HTML elements to a variable to be used for processing later.

Continuing with the script break down, we can see our WebRequest call, which stores the source code of the support page in a variable called $result.

$result = Invoke-WebRequest $url 

If you echo $result you will see an enormous amount of information, numerous elements, housing their respective properties each contain the corresponding values.

In order to reduce to this down into more usable objects, we only include the elements that have a class called "Plink". Plink is an HTML item which contains a hyperlink. Using this class will include ALL hyperlinks contained within the page. In our case this contains ALL the problematic KB article pages, with some additional links.

$elements = $result.AllElements | Where Class -eq "plink"

Echo'ing different properties of the object called $elements, we can see pertinent information. To find how many hyperlinks are contained within the class we can perform a count on the number of "PLINK". Powershell objects ($elements) automatically contains the .Count property:

Because $Elements is an object, and contains more than 1 item, we must iterate through each item. Taking the count from above into consideration, we can echo specific $element items to view all the associated properties and their values. The first item starts at [0] and goes to [12], since there are 13 total. Below we can see the first PLINK item's [0] data to work with:

By observing $elements[0], we now know the specific property to enumerate during the entire item iteration. In the end this property is used to generate the entire exclude KB list.

In PowerShell a ForEach loop automatically loops through all of a collection of items. In the current usage the collection is $elements with each item [X] assigned to the variable $link. Each time the loop occurs the $link is reset, meaning it only ever contains 1 value equal to the respective $elements[X].innertext. This string is then to be used in the processing section of the foreach loop.

foreach ($link in $elements.innertext)

{

*PROCESSING*

}

Each string $link to be processed is assumed to be a hyperlink, and the desired KB number is at the very end of the string. These two made assumptions must be validated, thus ensuring script reliability. For this example we only require the KB number, and nothing more.

To begin the necessary string cleansing, the position in the string, to begin processing must be known. For each line of $Elements.innerText or $link=(https://support.microsoft.com/kb/XXXXXXXX), we will set the variable $POS to the numerical position of the start of '/kb/'. The next 3 characters will always be 'kb/', knowing this simply adding 3 to move our position to the final / after KB, creates our desired starting point.

This position number is important because not only does it provide our initial modification location but also serves as a validation test. Remember earlier when the PLINK class was used as a filter, and it included all items with a hyperlink and not just instances of the KB hyperlink? By searching for '/KB/' specifically, all non KB hyperlinks are eliminated. If '/KB/' is not found $POS will equal -1, again, meaning '/KB' was not found.

Below is an example of the index number for items [1] and [12]:

Using an If statement, only valid KB hyperlink's will have an index number ($POS) greater than 3.

if ($pos -gt 3)

There are just a few more items to take into consideration when cleansing the KB hyperlink string. At this point the string is just '/#######*'. The document says * when in reality there are two different possibilities, which are a '/' or a ')'. It is inconsistent but simple enough to correct either. Using Powershell's substring method, provide a string, the starting point, and the length or number of characters to save.

In our example we use $link which currently is (https://support.microsoft.com/kb/2984976), move our starting point to $pos, or 32 characters in from the left, and save all the characters from the starting point to the end. We can dynamically control the characters being saved, (length) by taking the total string length and subtracting it from our starting point $pos and that equals the remainder of the string.

$link.Substring($pos,$link.Length-$pos)

When we do this and echo our sOutput variable we can see there is just one more tweak to do to completely cleanse the KB hyperlink. Below is that output:

The last item is to remove the '/' and ')' from each of the strings and the string cleansing will be complete. Luckily Powershell provides a Replace method much like the substring method. The replace method requires a string, the character to look for, and what to replace that character with.

We will simply replace both the '/' and ')' with nothing, and then ensure all trailing blank spaces are removed. Below is our needed replace scenario example:

$sOutput.Replace('/','').Replace(')','').Trim()

And finally the corresponding output:

At this point you all the KB numbers have been found and properly sanitized for use. Once sanitized how can this be put to use? Well of course we need to integrate it into the ConfigMgr deployment task sequence :).

Deployment

Some modifications needed to be made to the script in-order to make it usable during deployment. The overall script functionality is exactly the same as above, the modifications were made to make the script more memory efficient and functionally able to utilize Task Sequence environment variables.

CheckBadKB.ps1

 $i=1

$tsEnv = New-Object -ComObject Microsoft.SMS.TSEnvironment

$url = "https://support.microsoft.com/kb/2894518"

$result = Invoke-WebRequest $url 

$result.AllElements | Where Class -eq "plink" | ForEach-Object { 

$pos = $_.innertext.indexof('/kb/') + 3 

#If Valid KB Hyperlink

if ($pos -gt 3)

{

        #String Cleansing, final ExcludeKB = 1234567

        $ExcludeKB = $_.innertext.Substring($pos,$_.innertext.Length-$POS).Trim().Replace('/','').Replace(')','')    

        #This Write-Host can be found in CheckBadKB.log file.  

        #Run Powershell script step will output automatically to selfcreated log file

        Write-Host "WUMU_ExcludeKB$i=" $ExcludeKB

        $tsEnv.Value("WUMU_ExcludeKB$i") = $ExcludeKB

}

$i++ 

}

Task Sequence Modifications

This deployment section of the blog post is intended to provide an example methodology to prevent these problematic patches from applying during the ZTI TS. The components of this section should provide an 80% completed solution with the remaining 20% being requirements gathering and final implementation. The proper process to prevent these updates from failing your ZTI deployment, will vary from customer to customer based on their requirements. 

In this blog's example we have integrated MDT with Configuration Manager and no longer use the default Configuration Manager step "Install Software Updates". Instead the MDT script ZTIWindowsUpdate.wsf is called.

A few notes about using this demo methodology in production:

• This is not a supported Microsoft scenario, Microsoft will require the default Install Software Update Step be used, if problems arise.
• This will completely bypass the Software Update Point, and each client will download the updates either from a Standalone WSUS Server (if specified) or from Microsoft's public Windows Update site.

The CheckForBadKB.ps1 script currently needs to run Online and the client must have internet access. Below our two figures show how our example utilizes the example prevention process. 

Figure 1 shows a 'Run Powershell Script' step to run immediately before the demonstration step MDT Install Software Updates.

Figure 2 shows a 'Run Command Line' step to run the ZTIWIndowsUpdate.wsf script to apply Windows Updates

Verifying on Client Side

Once everything has been configured we need to verify on our client side that things are working. Once the CheckBadKB script runs it will generate a log file for itself, located in the normal SMS TS Log path locations. This CheckBadKB.log file should indicate all the KB's added to the exclude list. Below Highlighted in bold is that process happening:

CheckBadKB.log

<![LOG[WUMU_ExcludeKB1=]LOG]!><time="18:06:53.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[ ]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[2984976]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[WUMU_ExcludeKB2=]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[ ]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[2981685]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[WUMU_ExcludeKB3=]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[ ]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[2966034]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[WUMU_ExcludeKB4=]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[ ]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[2965788]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[WUMU_ExcludeKB5=]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[ ]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

<![LOG[2920189]LOG]!><time="18:06:54.000+000" date="11-28-2014" component="TaskSequencePSHost" context="" type="1" thread="" file="TaskSequencePSHost">

Once the Windows Update step starts to run, if we monitor the ZTIWindowsUpdate.log file we can see our targeted KB's, being skipped during the update installation process. Below in bold is that process occurring:

ZTIWindowsUpdate.log

<![LOG[INSTALL - b1d4e91a-26a7-4215-b0d5-7819b7ee125a - Windows Malicious Software Removal Tool for Windows 8, 8.1 and Windows Server 2012, 2012 R2 x64 Edition - November 2014 (KB890830) - 31 MB]LOG]!><time="21:52:17.000+000" date="11-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">

<![LOG[  SKIP  - c4f97de4-bdad-4d50-9a24-07d241040b0f - Security Update for Windows 8.1 for x64-based Systems (KB2920189) - 10 MB]LOG]!><time="21:52:17.000+000" date="11-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">

<![LOG[INSTALL - fb3da1f2-6a6e-4f4a-b25c-a05af3974acc - Security Update for Internet Explorer Flash Player for Windows 8.1 for x64-based Systems (KB3018943) - 17 MB]LOG]!><time="21:52:17.000+000" date="11-28-2014" component="ZTIWindowsUpdate" context="" type="1" thread="" file="ZTIWindowsUpdate">

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.

Most of the changes are internal improvements to the script.  I won’t go into most of those here but you can find the details in the header block and revision notes of the script.  One that I will discuss is the change to the handling of the KeyboardLocale setting.  MDT (and the unattend.xml InputLocale setting that MDT fills in with this value) allows this setting to be specified as language-REGION text (e.g. en-US) or hex codes (e.g. 0409:00000409).  The XML file generated by this script only supports the hex codes.  So now if the script sees a text entry in KeyboardLocale it will use ListOfLanguages.xml (in the Scripts folder of the MDT Deployment Share or MDT Toolkit ConfigMgr package) to convert it to hex codes.

One other change is that the script now supports a UILanguageFallback custom property to allow specification of the Fallback language when the UILanguage is not fully localized, like the unattend.xml setting: https://technet.microsoft.com/en-us/library/ff716433.aspx.

The engagement where I made these changes was a Windows 7 migration, so I have not had a chance to see if/how well this might work on Windows 8.x.  If you try this, post a comment about it here.

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.

RegionalSettings.zip