Announcing the AdventureWorks OData Feed sample



Update – Removing Built-in Applications from Windows 8


In October last year I published a script that is designed to remove the built-in Windows 8 applications when creating a Windows 8 image. After a reading some of the comments in that blog post I decided to create a new version of the script that is simpler to use. The new script removes the need to know the full name for the app and the different names for each architecture. I am sure you will agree that this name - Microsoft.Bing – is much easier to manage than this - Microsoft.Bing_1.2.0.137_x86__8wekyb3d8bbwe.

The script below takes a simple list of Apps and then removes the provisioned package and the package that is installed for the Administrator. To adjust the script for your requirements simply update the $AppList comma separated list to include the Apps you want to remove.

$AppsList = "Microsoft.Bing" , "Microsoft.BingFinance" , "Microsoft.BingMaps" , "Microsoft.BingNews",` 
            "Microsoft.BingSports" , "Microsoft.BingTravel" , "Microsoft.BingWeather" , "Microsoft.Camera",` 
            "microsoft.microsoftskydrive" , "Microsoft.Reader" , "microsoft.windowscommunicationsapps",` 
            "microsoft.windowsphotos" , "Microsoft.XboxLIVEGames" , "Microsoft.ZuneMusic",` 
            "Microsoft.ZuneVideo" , "Microsoft.Media.PlayReadyClient"

ForEach ($App in $AppsList)
{
    $PackageFullName = (Get-AppxPackage $App).PackageFullName
    if ((Get-AppxPackage $App).PackageFullName)
    {
        Write-Host "Removing Package: $App"
        remove-AppxProvisionedPackage -online -packagename $PackageFullName
        remove-AppxPackage -package $PackageFullName
    }
    else
    {
        Write-Host "Unable to find package: $App"
    }
}

 

When deleting applications I also recommend that you create and deploy a custom start screen layout using the export-layout command to export a layout they want to use and then apply the layout during deployment to the default user profile. If you do not use a custom start screen layout you may see a version of the start screen that only contains five tiles. For more information see my previous post - https://blogs.technet.com/b/deploymentguys/archive/2012/10/26/start-screen-customization-with-mdt-.aspx?pi36647=2.

For more information on adding and removing apps please refer to this TechNet article..

This post was contributed by Ben Hunter, a Solution Architect with Microsoft Consulting Services.

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 .


Using MBAM to start BitLocker Encryption in a Task Sequence


The script has been updated to abort if the TPM is not Active and to create Endorsement Key Pair if it does not exist on the TPM.

 

Microsoft BitLocker Administration and Monitoring (MBAM) provides features to manage BitLocker encryption of computers in an enterprise.  More information on MBAM can be found here.

BitLocker creates recovery information at the time of encryption and MBAM stores that information in the recovery data store. While MBAM can update its recovery data store when the agent is installed on a system that is already encrypted, it is preferable to have MBAM control the encryption process.  MBAM Encryption is controlled by Group Policy.  Group Policy is not applied during a SCCM Task Sequence.  It is possible to have MBAM start encryption during the task sequence, the techniques are described in the following whitepaper Using MBAM Data Encryption With MDT https://go.microsoft.com/fwlink/?LinkId=229053

Manually starting BitLocker Encryption with MBAM

Manually starting encryption with MABM requires five steps:

  1. Install the MBAM Agent. 
  2. Stop the MBAM agent
  3. Import registry settings that will instruct the agent to start encryption.
  4. Wait for encryption to start
  5. Remove the most of the imported registry settings

Installing MBAM Agent

The MBAM agent can be installed during Windows 7 Image creation. 

To install MBAM during the deployment, just create a SCCM package/program to install the agent.

Creating the registry import files.

Create a .reg file that contains the required MBAM entries. There is a template in Program Files\Microsoft\MDOP MBAM\MBAMDeploymentKeyTemplate.reg. This template will become the basis for the AddMBAMRegEntries.reg file.

Do the following on an unencrypted system with the MBAM Agent installed(from an elevated command prompt):

  1. Net Stop MBAMAGENT
  2. reg import "c:\Program Files\Microsoft\MDOP MBAM\MBAMDeploymentKeyTemplate.reg"
  3. using regedit make the following changes:
    1. Change the KeyRecoveryServiceEndPoint key to have the URL of the MBAM recovery server.
    2. Add NoStartupDelay as a DWORD with a value of one.
  4. Export the MBAM key to a file (AddMBAMRegEntries.reg)

Next, create a .reg file to remove the entries

  1. Copy AddMBAMRegEntries.reg to RemoveMBAMRegEntries.reg
  2. Open RemoveMBAMEntries.reg in notepad
  3. Delete the line: "Installed"=dword:00000001
  4. for all the other keys in the file replace everything after the equals sign with a minus sign (E.G. "NoStartupDelay"=dword:00000001 becomes "NoStartupDelay"=-)
  5. Save RemoveMBAMRegEntries.reg

Note: More information on creating and editing .reg files is available here.

At this point test that the .reg files are correct by starting the MBAM agent (net Start MBAMAGENT), encryption will begin within a couple of minutes.  After encryption begins, run the removeMBAMEntries.reg file to remove the unneeded entries.

For encryption to begin, the MBAM agent needs to talk to the server.  If this server communication fails the encryption will not start.  If there is a problem, verify that the URL is correct and the MBAM server is functioning correctly.

Sample AddMBAMRegEntries.reg file

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MBAM]
"Installed"=dword:00000001
"KeyRecoveryOptions"=dword:00000001
"UseKeyRecoveryService"=dword:00000001
"KeyRecoveryServiceEndPoint"=hex(2):68,00,74,00,74,00,70,00,73,00,3a,00,2f,00,\
2f,00,63,00,69,00,73,00,35,00,33,00,33,00,76,00,6d,00,6d,00,62,00,61,00,6d,\
00,2e,00,61,00,76,00,6e,00,65,00,74,00,2e,00,63,00,6f,00,6d,00,2f,00,4d,00,\
42,00,41,00,4d,00,52,00,65,00,63,00,6f,00,76,00,65,00,72,00,79,00,41,00,6e,\
00,64,00,48,00,61,00,72,00,64,00,77,00,61,00,72,00,65,00,53,00,65,00,72,00,\
76,00,69,00,63,00,65,00,2f,00,43,00,6f,00,72,00,65,00,53,00,65,00,72,00,76,\
00,69,00,63,00,65,00,2e,00,73,00,76,00,63,00,00,00
"DeploymentTime"=dword:00000001
"NoStartupDelay"=dword:00000001

Sample RemoveMBAMRegEntries.reg file

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MBAM]
"KeyRecoveryOptions"=-
"UseKeyRecoveryService"=-
"KeyRecoveryServiceEndPoint"=-
"DeploymentTime"=-
"NoStartupDelay"=-

 

Automating the process with a script

StartMBAMEncryption.wsf is a MDT 2010 style script that will automate the last four steps   To use this script create a folder that contains StartMBAMEncryption.wsf, ZTIUtility.vbs from the MDT toolkit, and the two .reg files created above. 

To start Encryption run the following from an elevated command prompt:

cscript StartMBAMEncryption.wsf /AddRegFile:AddMBAMRegEntries.reg /RemoveRegFile:RemoveMBAMRegEntries.reg

How does the script work?

Make sure that MBAM is installed, do a WMI query for the MBAMAGENT service. If the service does not exist, fail.

    Set oServices = objWMI.ExecQuery("Select * from win32_service where name='MBAMAgent'")
    TestAndFail (oServices.count = 1), 10005, "MBAM Client Agent is not installed"

The service exists,  stop the service.  Using the result of the previous query, call the StopService method.  Note that the query will return at most one item.

    
    'Stop the service
    for each oService in oServices
      oService.StopService()
    Next

Use the REG IMPORT command to import the  AddMBAMRegEntries.reg file, this will give the MBAM agent instruction to start encryption.

 
    sCMD = "Reg IMPORT """ & sAddRefFilePath & """"
    iRetVal = oUtility.RunWithHeartbeat(sCMD)
    TestAndFail iretVal, 10006, "Importing AddRegFile: " & sAddRefFilePath

Now, using the result of the original WMI query again, start the MBAM agent

    ' Restart the MBAMAgent Service
    for each oService in oServices
      oService.StartService()
    Next

Since BitLocker information is in a different Namespace, the script must create a connection to that Namespace.

    strConnectionStr1 = "winmgmts:{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!root\cimv2\Security\MicrosoftVolumeEncryption" 
    On Error resume Next
    Set objWMIBDE = GetObject(strConnectionStr1)
    on error goto 0
    TestAndFail Err, 10007, "Unable to connect to Bitlocker WMI Object -  bitlocker not installed"

Using the object just created, query for a Win32_EncryptableVolume for the C: drive. Once that object is obtained, go into a loop sleeping 30 seconds, updating the Task Sequence progress bar, and checking to see if the encryption is in progress.  Note that the script is checking for both in progress (EncryptionStatus = 2) and Encrypted (EncryptionStatus = 1).  This loop will wait 10 minutes for the encryption to start.  In testing the encryption has started within 2 minutes.

    iCount = 0
    iLoopCount = 0
    oLogging.CreateEntry "Waiting for Encryption to Start", LogTypeInfo
    Do
      oLogging.ReportProgress "Waiting For Encryptiont to Start",  iLoopCount/20
      wscript.Sleep 30000
      Set colEnVol = objWMIBDE.ExecQuery("Select * from Win32_EncryptableVolume where DriveLetter='C:'")
      for each oEncVol in colEnVol
      oEncVol.GetConversionStatus iEncryptionStatus, iPercentComplete
      Next

      ILoopCount = iLoopCount + 1
      If iLoopCount >= 20 then
        TestAndFail False, 10008, "Timeout: Encryption did not start"
      End If
    Loop Until ((iEncryptionStatus = 1) or (iEncryptionStatus = 2))
    oLogging.ReportProgress "Encryptiont Started", 100
    oLogging.CreateEntry "Encryptiont Started", LogTypeInfo

All that is left to do is cleanup the registry by importing the removeMBAMEntries.reg file

    sCMD = "Reg IMPORT """ & sRemoveRegFilePath & """"
    iRetVal = oUtility.RunWithHeartbeat(sCMD)
    TestAndFail iretVal, 10009, "Importing RemoveRegFile: " & sRemoveRegFilePath

 

Creating the MBAM Support Task Sequence Package

Create a new folder and add the two .reg files created above, a copy of ZTIUTILITY.VBS from the MDT scripts package, and StartMBAMEncryption.wsf.  In you SCCM console, create a new package, and program.  The program command line will be:

cscript StartMBAMEncryption.wsf /AddRegFile:AddMBAMRegEntries.reg /RemoveRegFile:RemoveMBAMRegEntries.reg  

Or, to wait until encryption is finished, before the task sequence continues, the program command line will be:

  cscript StartMBAMEncryption.wsf /AddRegFile:AddMBAMRegEntries.reg /RemoveRegFile:RemoveMBAMRegEntries.reg /WaitForEncryption:true

  

Changes to the Task Sequence

TPM Issues

The Trusted Platform Module (TPM) must be visible to the OS and enabled.  making the TPM visible, varies by hardware vendor and system.  There is a script that will check if the TPM is visible Here.    For information on how to enable the TPM from a task sequence see the table below.

Lenovo https://support.lenovo.com/en_US/detail.page?LegacyDocID=MIGR-68488

Dell

https://en.community.dell.com/techcenter/os-applications/w/wiki/how-to-enable-trusted-platform-module-using-a-configmgr-2007-task-sequence.aspx
HP https://itbloggen.se/cs/blogs/micke/archive/2010/10/18/enable-tpm-via-task-sequence-on-hp-boxes.aspx

 

Disk Partitioning

BitLocker requires an unencrypted partition that will hold the Boot files and boot database.  This partition has to be at least 100MB, but it is recommended that it be 300MB.  A 300MB partition will allow recovery environment (WinRE) to be copied to the unencrypted drive.  WinRE is automatically copied when BitLocker is enabled if there is enough space on the boot partition.

For Bare Metal deployments, the partition can be created during the Partition Disk step.

  1. Create a 300MB primary partition and mark it Active (Make Bootable)  
  2. Create a primary partition that uses 100% of the remaining disk  Assign a variable to this disk (OSDISK)
  3. Change the Apply Operating System step to put the Operating System on the disk specified in the variable OSDISK

image

image

image

image

For refresh from XP or Windows 7 system that does not have a separate boot partition, use the following steps:

 

The following steps should be added before the step that installs the MBAM support package created above.

Using ZTIBDE.WSF (from MDT)

Add a Run Command Line step that runs ZTIBDE.WSF

Cscript %ScriptRoot%\ztibde.wsf

Using BdeHDCfg

Add a Run Command Line step  with the following command line:

BdeHdCfg -target default -quiet

This will create a 300MB partition for the boot files.  

Add a Reboot System step following this step.

Additional information on BitLocker, Configuration Manager 2007, and disk partitions can be found on the Configuration manager Support Team blog https://blogs.technet.com/b/configurationmgr/archive/2011/01/20/solution-the-enable-bitlocker-task-fails-to-run-during-a-configmgr-2007-task-sequence.aspx

Join the Domain

The computer system must be in a Domain in order for MBAM to escrow the BitLocker Keys. 

Joining a domain is required for this process to work correctly.

Enabling BitLocker

To enable BitLocker, simply add an install software step to install the package/program created above.  It is recommended that this be one of the last steps in the Task Sequence because encrypting the disk will consume many system resources until the disk is fully encrypted.

Waiting for Encryption to Finish

To ensure the highest security level, the system should not be released to a user until the disk is completely encrypted.  The /WaitForEncryption:True option will force the script to wait up to 5 hours for the encryption to finish.  If the encryption doesn't finish within 5 hours, the fact will be logged but the script will not abort.  This option can be useful if there are business requirements that the system be fully encrypted before any data is restored.

cscript StartMBAMEncryption.wsf /AddRegFile:AddMBAMRegEntries.reg /RemoveRegFile:RemoveMBAMRegEntries.reg /WaitForEncryption:true

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

Special thanks to Manoj Sehgal, Senior Support Escalation Engineer, Platforms core, Microsoft Services, and William Lees, Principal SDE, Microsoft Corporation, for their assistance with this post.

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

StartMBAMEncryption.zip


USMT: Architecture-Independent Rules for Migrating 32-bit Applications


Update 2014-04-16:   I forgot to include that fact that a locationModify rule is required when using the %HklmWowSoftware% variable.  The post has been updated to reflect this.

 

One challenge with capturing the settings for a 32-bit applications with USMT is that some file and Registry paths will be different on 32-bit operating systems and 64-bit operating systems.  On a 32-bit operating system 32-bit programs typically get installed to C:\Program Files and local machine Registry entries are written to a subkey of HKLM\Software.  However, on a 64-bit operating system , 32-bit programs get installed to C:\Program Files (x86) and HKLM\Software Registry entries are redirected to HKLM\SOFTWARE\Wow6432Node.  (I have oversimplified this here for brevity's sake.  See this section of the Programming Guide for 64-bit Windows for more details: https://msdn.microsoft.com/en-us/library/aa384249(v=vs.85).aspx.)

Because of this, you might think you would need to different components to migrate 32-bit application settings depending on the source and destination operating system architecture.  For example, I had a customer that was using three different XML files with components for 32-bit applications.  I'll illustrate this using a fictitious 32-bit application called MyApp.  This application is installed by default to C:\Program Files\MyApp and creates machine-based settings in HKLM\Software\MyApp on a 32-bit OS.  For the sake of simplicity for this example, lets say that the desired way to migrate this app is to capture all the files in the C:\Program Files\MyApp\Config folder and to capture all of HKLM\Software\MyApp (or the equivalent locations on a 64-bit OS).

The customer had three different migration scenarios:

  • Windows XP 32-bit to Windows XP 32-bit (break/fix rebuilds, etc.)
  • Windows XP 32-bit to Windows 7 64-bit (OS migration)
  • Windows 7 64-bit to Windows 7 64-bit (break/fix rebuilds, etc.)

For Windows XP 32-bit to Windows XP 32-bit migrations they had a component like this for MyApp.

<component type="Application" context="System">
<displayName>Migrate MyApp - XP to XP</displayName>
<role role="Settings">
<rules>
<include>
<objectSet>
<pattern type="File">%CSIDL_PROGRAM_FILES%\MyApp\Config\* [*]</pattern>
<pattern type="Registry">HKLM\Software\MyApp\* [*]</pattern>
</objectSet>
</include>
</rules>
</role>
</component>

For Windows XP 32-bit to Windows 7 64-bit migrations they had a component like this for MyApp.  This has locationModify rules to move the migrated items to the redirected locations for 32-bit apps on 64-bit Windows.

<component type="Application" context="System">
<displayName>Migrate MyApp - XP to Win7</displayName>
<role role="Settings">
<rules>
<include>
<objectSet>
<pattern type="File">%CSIDL_PROGRAM_FILES%\MyApp\Config\* [*]</pattern>
<pattern type="Registry">HKLM\Software\MyApp\* [*]</pattern>
</objectSet>
</include>
<locationModify script="MigXmlHelper.RelativeMove('%CSIDL_PROGRAM_FILES%\MyApp\Config','%CSIDL_PROGRAM_FILESX86%\MyApp\Config')">
<objectSet>
<pattern type="File">%CSIDL_PROGRAM_FILES%\MyApp\Config\* [*]</pattern>
</objectSet>
</locationModify>
<locationModify script="MigXmlHelper.RelativeMove('HKLM\Software\MyApp','HKLM\SOFTWARE\Wow6432Node\MyApp')">
<objectSet>
<pattern type="Registry">HKLM\Software\MyApp\* [*]</pattern>
</objectSet>
</locationModify>
</rules>
</role>
</component>

For Windows 7 64-bit to Windows 7 64-bit migrations they had a component like this for MyApp which directly captured/restored the redirected locations for the 32-bit app on 64-bit Windows.

<component type="Application" context="System">
<displayName>Migrate MyApp - Win7 to Win7</displayName>
<role role="Settings">
<rules>
<include>
<objectSet>
<pattern type="File">%CSIDL_PROGRAM_FILESX86%\MyApp\Config\* [*]</pattern>
<pattern type="Registry">HKLM\SOFTWARE\Wow6432Node\MyApp\* [*]</pattern>
</objectSet>
</include>
</rules>
</role>
</component>

Of course, this makes it complicated to call USMT with the correct XML file depending on what source and destination operating systems were involved.  Fortunately, there is a way to avoid this.  It involves using a technique I lifted directly from MigApp.xml.  MigApp.xml contains a namedElements node that defines a bunch of global items.  Some of these items define single variables representing the file and local machine Registry locations for 32-bit applications independent of the operating system architecture.  You can copy this into your own custom XML files and use those variables in the same way.  Copy the XML content below into your custom XML files (just after the migration node at the top)

<library prefix="MigSysHelper">MigSys.dll</library>

<_locDefinition>
<_locDefault _loc="locNone"/>
<_locTag _loc="locData">displayName</_locTag>
</_locDefinition>

<namedElements>
<!-- Global -->
<environment name="GlobalEnvX64">
<conditions>
<condition>MigXmlHelper.IsNative64Bit()</condition>
</conditions>
<variable name="HklmWowSoftware">
<text>HKLM\SOFTWARE\Wow6432Node</text>
</variable>
<variable name="ProgramFiles32bit">
<text>%ProgramFiles(x86)%</text>
</variable>
<variable name="CommonProgramFiles32bit">
<text>%CommonProgramFiles(x86)%</text>
</variable>
</environment>
<environment name="GlobalEnv">
<conditions>
<condition negation="Yes">MigXmlHelper.IsNative64Bit()</condition>
</conditions>
<variable name="HklmWowSoftware">
<text>HKLM\Software</text>
</variable>
<variable name="ProgramFiles32bit">
<text>%ProgramFiles%</text>
</variable>
<variable name="CommonProgramFiles32bit">
<text>%CommonProgramFiles%</text>
</variable>
</environment>

    <!-- Global USER -->
<environment context="USER" name="GlobalEnvX64User">
<conditions>
<condition>MigXmlHelper.IsNative64Bit()</condition>
</conditions>
<variable name="VirtualStore_ProgramFiles32bit">
<text>%CSIDL_VIRTUALSTORE_PROGRAMFILES(X86)%</text>
</variable>
<variable name="VirtualStore_CommonProgramFiles32bit">
<text>%CSIDL_VIRTUALSTORE_COMMONPROGRAMFILES(X86)%</text>
</variable>
</environment>
<environment context="USER" name="GlobalEnvUser">
<conditions>
<condition negation="Yes">MigXmlHelper.IsNative64Bit()</condition>
</conditions>
<variable name="VirtualStore_ProgramFiles32bit">
<text>%CSIDL_VIRTUALSTORE_PROGRAMFILES%</text>
</variable>
<variable name="VirtualStore_CommonProgramFiles32bit">
<text>%CSIDL_VIRTUALSTORE_COMMONPROGRAMFILES%</text>
</variable>
</environment>
</namedElements>

Once you add this, you can now define one component to migrate MyApp that will work in all three scenarios:

<component type="Application" context="System">
<displayName>Migrate MyApp</displayName>
<environment name="GlobalEnv"/>
<environment name="GlobalEnvX64"/>
<environment name="GlobalEnvUser"/>
<environment name="GlobalEnvX64User"/>
<role role="Settings">
<rules>
<include>
<objectSet>
<pattern type="File">%ProgramFiles32bit%\MyApp\Config\* [*]</pattern>
<pattern type="Registry">%HklmWowSoftware%\MyApp\* [*]</pattern>
</objectSet>
</include>
<locationModify script="MigXmlHelper.RelativeMove('%HklmWowSoftware%','%HklmWowSoftware%')">
<objectSet>
<pattern type="Registry">%HklmWowSoftware%\MyApp\* [*]</pattern>
</objectSet>
</locationModify>
</rules>
</role>
</component>

The variable %ProgramFiles32bit% will resolve correctly to C:\Program Files on a 32-bit OS and C:\Program Files (x86) on a 64-bit OS.  The variable %HklmWowSoftware% will resolve correctly to HKLM\Software on a 32-bit OS and HKLM\SOFTWARE\Wow6432Node on a 64-bit OS.

Note that you need to add four environment nodes shown in the above example into your components that will use these variables.  This is essentially adding a "reference" to the namedElements items that define the variables.

You also need a locationModify rule like the one show above when using the %HklmWowSoftware% variable.  It may seem odd to need a location modify that has the same source and destination location.  However, this is needed because USMT does not automatically redirect Registry locations.  It will try to write them back to the original location.  Fortunately, the locationModify RelativeMove function will expand the environment variables of the first parameter in the context of the source machine and the second parameter in the context of the destination machine.  This will cause the Registry entries to be redirected properly.

You may be wondering if you need to worry about redirection of HKCU Registry entries for 32-bit applications.  You don't.  For most of HKCU, 32-bit apps write to HKCU without redirection (See https://msdn.microsoft.com/en-us/library/aa384232(v=vs.85).aspx for details).

 

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


USMT Capture Status Notification HTA in Full Operating System


 

 

Recently, I had a customer that wanted separate, stand-alone USMT Capture and USMT Restore task sequences.  They had key depot locations that would allow users to drop off an old machine, and have the depot technicians image and restore data to a new device.  They would then repurpose the old machine.

Evidently, they had issues with USMT not running successfully or perhaps it was forgotten by the technician in the first place.  So they asked for a notification box to pop up and let the technician know the data was, in fact, captured successfully.

The requirement was to make a notification box pop up and pause the task sequence until it is acknowledged or closed. 

I created a simple HTA that will look for the scanstate.log in the CCM\Logs\SMSTSlog folder based on architecture.  As I am sure you are aware, the SMSTSLog folder is where the logs are placed during the task sequence, so they are always guaranteed to be current.  It isn't until the task sequence is closed out that the logs are moved one level up and the SMSTSLog folder removed.

If they are running on a Windows XP machine the path is:

C:\Windows\System32\CCM\Logs\SMSTSLog\scanstate.log.

If they are running on a Windows 7 x64 machine, the path is:

C:\Windows\SysWow64\CCM\Logs\SMSTSLog\scanstate.log

 

The HTA then parses this log file looking for 'MIGACTIVITY_SUCCESS'.  If this message exists in the log file, the HTA returns the following box…

image

 

If it doesn't exist, they see the following box…

image

 

Now that the HTA is functional, I have to put it in the task sequence and make it visible while running inside the full operating system.  This is where the fun really begins…

Luckily, we can take advantage of ServiceUi.exe that exists in the Tools\x86 or Tools\x64 folders within the Microsoft Deployment Toolkit package.  We can launch this by calling it from %toolroot%.

Placing my HTA file in a folder called CustomScripts underneath the Scripts folder in the toolkit package allows me to use the command line…

%toolroot%\serviceui.exe –process:tsprogressui.exe %systemroot%\system32\mshta.exe %scriptroot%\CustomScripts\USMTCaptureStatus.hta

Here is an example of how to call my HTA using the ServiceUi.exe…

CaptureNotificationTaskCommand

 

 

 

For more information on the use of ServiceUI.exe, see 'Can I use ServiceUI.exe to launch other programs besides the UDI Setup Wizard?' on Cameron's Blog – Cravings of System Center.

 

USMTCaptureStatus.hta

<html>
< head>
< title>USMT Capture Status</title>
< HTA:APPLICATION
APPLICATIONNAME="USMT Capture Status"
ID="USMTCaptureStatus"
SCROLL="no"/>
< /head>

<script language="VBScript">

' *****************
' * Window_OnLoad *
' *****************

Sub Window_OnLoad
'This method will be called when the application loads
window.resizeTo 600,300
window.moveto 1,1
USMTStatus
End Sub

' *****************
' * USMTStatus *
' *****************

Sub USMTStatus
Const ForReading = 1

' Set the search parameter
Set objRegEx = CreateObject("VBScript.RegExp")
objRegEx.Pattern = "MIGACTIVITY_SUCCESS"

' Prepare log file connectivity
Set objFSO = CreateObject("Scripting.FileSystemObject")

' WMI Connectivity
strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

' Query WMI for processor architecture type
Set colProcessors= objWMIService.ExecQuery ("Select * From Win32_Processor")

' Set log file location based on processor architecture type
For Each objProcessor in colProcessors
If objProcessor.Architecture = 0 Then
Set objFile = objFSO.OpenTextFile("C:\windows\system32\ccm\logs\SMSTSLog\scanstate.log", ForReading)
Else
Set objFile = objFSO.OpenTextFile("C:\windows\syswow64\ccm\logs\SMSTSLog\scanstate.log", ForReading)
End If

' Set initial returnSuccess to 'False'
returnSuccess = False

' Parse the scanstate.log file for search parameters
Do Until objFile.AtEndOfStream
strSearchString = objFile.ReadLine
Set colMatches = objRegEx.Execute(strSearchString)
If colMatches.Count > 0 Then
For Each strMatch in colMatches
returnSuccess = True
Next
End If
Loop

' Set HTA pop-up box text based on search results
If returnSuccess = True Then
DataArea.InnerHTML = "The user state was SUCCESSFULLY captured.<br><br>PLEASE CLOSE THIS BOX TO END THE TASK SEQUENCE."
Else
DataArea.InnerHTML = "The user state was NOT SUCCESSFULLY captured.<br><br>PLEASE CLOSE THIS BOX TO END THE TASK SEQUENCE."
End If

 

Next

End Sub   

 

< /script>

<body bgcolor= "white">

<span id = "DataArea"> </span>

<!--{{InsertControlsHere}}-Do not remove this line-->

</body>
< /html>

USMTCaptureStatus.zip

 

 

This post was contributed by Brad Tucker, a Senior Consultant with Microsoft Services, East Region, United States

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


USMT Restore Status Notification HTA in Full Operating System


In my previous blog entry, I explained my customer's need for stand-alone USMT Capture and USMT Restore task sequences and their need for a notification box to pop up and let the technicians know the process completed successfully.  This post will continue in that vein and discuss the notification HTA for the USMT Restore task sequence.

The requirement was to make a notification box pop up and pause the task sequence until it is acknowledged or closed. 

I created a simple HTA that will look for the loadstate.log in the CCM\Logs\SMSTSlog folder based on architecture.  As I am sure you are aware, the SMSTSLog folder is where the logs are placed during the task sequence, so they are always guaranteed to be current.  It isn't until the task sequence is closed out that the logs are moved one level up and the SMSTSLog folder removed.

If they are running on a Windows XP machine the path is:

C:\Windows\System32\CCM\Logs\SMSTSLog\loadstate.log.

If they are running on a Windows 7 x64 machine, the path is:

C:\Windows\SysWow64\CCM\Logs\SMSTSLog\loadstate.log

 

The HTA then parses this log file looking for 'MIGACTIVITY_SUCCESS'.  If this message exists in the log file, the HTA returns the following box…

image

 

If it doesn't exist, they see the following box…

image

 

Now that the HTA is functional, I have to put it in the task sequence and make it visible while running inside the full operating system.  This is where the fun really begins…

Luckily, we can take advantage of ServiceUi.exe that exists in the Tools\x86 or Tools\x64 folders within the Microsoft Deployment Toolkit package.  We can launch this by calling it from %toolroot%.

Placing my HTA file in a folder called CustomScripts underneath the Scripts folder in the toolkit package allows me to use the command line…

%toolroot%\serviceui.exe –process:tsprogressui.exe %systemroot%\system32\mshta.exe %scriptroot%\CustomScripts\USMTRestoreStatus.hta

Here is an example of how to call my HTA using the ServiceUi.exe…

RestoreNotificationTaskCommand

 

 

 

For more information on the use of ServiceUI.exe, see 'Can I use ServiceUI.exe to launch other programs besides the UDI Setup Wizard?' on Cameron's Blog – Cravings of System Center.

 

USMTRestoreStatus.hta

<html>
< head>
< title>USMT Restore Status</title>
< HTA:APPLICATION
APPLICATIONNAME="USMT Restore Status"
ID="USMTRestoreStatus"
SCROLL="no"/>
< /head>

<script language="VBScript">

' *****************
' * Window_OnLoad *
' *****************

Sub Window_OnLoad
'This method will be called when the application loads
window.resizeTo 600,300
window.moveto 1,1
USMTStatus
End Sub

' *****************
' * USMTStatus *
' *****************

Sub USMTStatus
Const ForReading = 1

' Set the search parameter
Set objRegEx = CreateObject("VBScript.RegExp")
objRegEx.Pattern = "MIGACTIVITY_SUCCESS"

' Prepare log file connectivity
Set objFSO = CreateObject("Scripting.FileSystemObject")

' WMI Connectivity
strComputer = "."
Set objWMIService = GetObject("winmgmts:" & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

' Query WMI for processor architecture type
Set colProcessors= objWMIService.ExecQuery ("Select * From Win32_Processor")

' Set log file location based on processor architecture type
For Each objProcessor in colProcessors
If objProcessor.Architecture = 0 Then
Set objFile = objFSO.OpenTextFile("C:\windows\system32\ccm\logs\SMSTSLog\loadstate.log", ForReading)
Else
Set objFile = objFSO.OpenTextFile("C:\windows\syswow64\ccm\logs\SMSTSLog\loadstate.log", ForReading)
End If

' Set initial returnSuccess to 'False'
returnSuccess = False

' Parse the scanstate.log file for search parameters
Do Until objFile.AtEndOfStream
strSearchString = objFile.ReadLine
Set colMatches = objRegEx.Execute(strSearchString)
If colMatches.Count > 0 Then
For Each strMatch in colMatches
returnSuccess = True
Next
End If
Loop

' Set HTA pop-up box text based on search results
If returnSuccess = True Then
DataArea.InnerHTML = "The user state was SUCCESSFULLY restored.<br><br>PLEASE CLOSE THIS BOX TO END THE TASK SEQUENCE."
Else
DataArea.InnerHTML = "The user state was NOT SUCCESSFULLY restored.<br><br>PLEASE CLOSE THIS BOX TO END THE TASK SEQUENCE."
End If

 

Next

End Sub   

 

< /script>

<body bgcolor= "white">

<span id = "DataArea"> </span>

<!--{{InsertControlsHere}}-Do not remove this line-->

</body>
< /html>

USMTRestoreStatus.hta

     
 

 

This post was contributed by Brad Tucker, a Senior Consultant with Microsoft Services, East Region, United States

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


Windows 10 Start Layout Customization


This Windows 10 Start Layout Customization guide provides detailed guidance on how organizations can customize the Windows 10 Start layout. Organizations often desire to deploy a customized Start layout on their devices to help direct users to specific applications.

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

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

 

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.


Windows 7 Deployment Options for Small and Midsize Businesses


Happy new year to everyone!  It looks like I am making the first blog post here for 2012 :-)

To get the year rolling I thought I'd share anexcellent resource that I stumbled across this week, even though it was published back in November.  If you follow the link below you can download a printable overview poster of the Windows 7 deployment options that has been specifically designed for small and midsize organizations.  As you can see in the small extract below each option is shown as a simple diagram and then the advantages and limitations of each one are discussed in detail further on.  Also included in the poster are the limitations, basic requirements and helpful links to tools and further guidance, as well as a step-by-step overview of the Windows 7 deployment process.

I hope it is of use, and if you know of any other similar resources (both Microsoft and non-Microsoft) feel free to share them with our readers using the comments section below.  See here for more information and the download links.

 

This post was contributed by Daniel Oxley, a Senior Consultant with Microsoft Services UK

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