Your SlideShare is downloading. ×

Windows RT 8.1 - Deployment Guide for Education

4,100

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
4,100
On Slideshare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
78
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Deploying Windows RT 8.1 A guide for education January 2014
  • 2. Table of contents 2 Choosing a student account 4 Deployment process overview 5 Shared-device scenarios 7 One-to-one scenarios 9 Creating the configuration store 10 Apps 11 Files 11 Logs 13 Policies 16 Profiles 17 Settings 18 Tasks 21 Updates 22 Users 24 Building a complete solution 26 Preparing shared devices for delivery 33 Preparing personal devices for delivery 45 Local Group Policy settings
  • 3. Deploying Windows RT 8.1 A guide for education This guide prescribes processes and provides a sample script framework that is specific to Windows RT device deployment in schools. It is based on observations from and work done at several schools deploying Surface devices. Surface and similar Windows RT 8.1 devices are great for students and educators: They are ultraportable, sturdy, and inexpensive. Students can use Windows RT devices to watch videos, write reports, and collaborate on group projects. Surface even has a built-in kickstand and integrated keyboard, allowing users to learn and teach the way they want. Deploying Windows RT devices in schools is different from deploying PCs, though. Windows RT devices are not PCs: They are tablets. You do not deploy them like PCs, and you do not manage them like PCs. A mobile technology similar to Apple iPad and other such tablets, Windows RT devices have limitations about which schools should be aware. You can learn more about these limitations by reading the white paper, Windows RT 8.1 in the Enterprise, at http://aka.ms/ windowsrt4enterprise. The guide you are reading now describes how schools can effectively deploy Windows RT devices. It helps them choose the right type of user account and automate much of the configuration process. It also provides sample Windows PowerShell scripts for both shared and one-to-one scenarios that schools can customize and extend to automate device configuration. NOTE  The listings in this guide are formatted for print media. Do not copy and paste them from this guide. Instead, download the sample scripts from the TechNet Script Center at http://gallery.technet. microsoft.com/scriptcenter/Windows-RT-81-configuration-6b06b65a. Download edu_config.zip and extract its contents to a USB flash drive or another location. The contents include the template folder structure and scripts. DEPLOYING WINDOWS RT 8.1 1
  • 4. Choosing a student account When planning to deploy Windows RT devices in schools, you will encounter four types of accounts: • Local Windows accounts  These accounts are local to the Windows RT device. They are the same as local accounts in earlier Windows operating system versions. In Windows RT, local accounts still have full Internet access and can run some Windows Store apps that do not require a Microsoft account. • Microsoft accounts (previously known as Windows Live ID)  These are consumer-oriented, Internet-based accounts that people use to access the Windows Store, SkyDrive, and other services that require them. Microsoft accounts are individually owned and cannot be accessed or managed by organizations, such as schools. Schools should not sign students up for Microsoft accounts, nor should they bulk-manage Microsoft accounts for students. For more information about Microsoft accounts, see “Microsoft accounts” at http://windows.microsoft. com/en-us/windows-8/microsoft-account-tutorial. • Domain Windows accounts  These accounts are in Active Directory Domain Services. You cannot sign in to Windows RT devices by using a domain account, but after students sign in to their devices using a local or Microsoft account, they can authenticate to network resources (e.g., network filters, file shares) by using their domain accounts. • Organizational accounts  Also known as Windows Azure Active Directory accounts, these are organization-oriented, Internet-based accounts that people use to access an organization’s subscription services, such as Microsoft Office 365 or Windows Intune. The school owns organizational accounts, and its IT staff manage them. Schools can synchronize their onpremises Active Directory infrastructure with Windows Azure AD. NOTE  Microsoft accounts in the United States comply with the Children’s Online Privacy Protection Act (COPPA) regarding online account creation for children under 13 years of age. They require parental consent, which parents give by charging a small amount to their credit card (for a U.S. account). Parental consent is not required to create Windows or organizational accounts, but Microsoft recommends that schools notify parents and obtain their consent before creating such accounts for students. For more information, see “Why does Microsoft charge me when I create an account for my child?” at http://windows.microsoft.com/en-us/ windows-live/family-safety-why-does. DEPLOYING WINDOWS RT 8.1 2
  • 5. Of the four account types, you can only use local Windows accounts or Microsoft accounts to sign in to Windows RT devices. With either type of account, students can subsequently use domain accounts to access network resources or organization accounts to access Office 365. The choice between local or Microsoft accounts depends largely on your deployment scenario. In shared-device scenarios, schools should use local accounts for device access combined with domain and organizational accounts for resource access. In one-to-one scenarios, schools might consider allowing users to sign in to their devices by using their own Microsoft accounts. They must still comply with COPPA, however, so parents of children under 13 years of age must create their children’s accounts. DEPLOYING WINDOWS RT 8.1 NOTE Microsoft prevents the creation of more than three Microsoft accounts from a single IP address in a single day. This limitation affects schools in which network address translation or a proxy server provides Internet access. Schools can contact Microsoft Support for an exception to this policy, however. For more information about gaining an exception to this policy, consult your account team. 3
  • 6. Deployment process overview This guide prescribes processes and provides sample Windows PowerShell scripts that are specific to Windows RT device deployment in schools. The processes and scripts are based on observations from and work done at several schools deploying Surface devices. The processes and scripts in this guide support two scenarios (see Table 1 for a brief comparison): • Shared-device scenarios  In shared-device scenarios, Microsoft recommends signing in to the device as an administrator and configuring shared local accounts on it before placing it in the classroom. • One-to-one scenarios  In one-to-one scenarios, Microsoft recommends starting the device in Audit mode, configuring it, and then using the System Preparation Tool (Sysprep) to seal it before delivering it to the student. Students sign in to their devices using Microsoft accounts. Table 1  Scenario comparison Shared scenario One-to-one scenario Recommended account type Local Windows account Microsoft account Student account privilege level Standard user accounts Administrator accounts Unnecessary Students under 13 years of age must have parental consent Must prevent students from caching their credentials and saving files to the local device Because students do not share their devices, their information is private as long as they protect their credentials Students can install apps from the Windows Store No Yes Access files on SkyDrive No Yes Use the Mail app with Office 365 or an on-premises mail server No Yes COPPA compliance Privacy considerations DEPLOYING WINDOWS RT 8.1 4
  • 7. Shared scenario One-to-one scenario Potential for misuse Some; students do have some anonymity when using shared devices, but you can identify a device’s user if you require students to use domain credentials to sign in to the network firewall Some; students do not have anonymity, but they do have full administrator access to their devices to install apps, configure settings, and so on Deployment interaction Significant interaction to complete the Out-of-Box Experience (OOBE) but automated afterward Light interaction that skips the OOBE and automated afterward A consideration that makes deploying Windows RT devices in schools different from other environments is the sheer volume over time. It is not uncommon for a school to have a dozen or more employees, each preparing 30 or more devices at a time (i.e., asynchronously). Therefore, capabilities like logging each device in an asset database can be challenging because doing so requires multiuser access. This guide does not attempt to solve these types of problems. Shared-device scenarios In a shared-device scenario, students use a device without concern for the user account accessing the device. In fact, students might not even know the name of the account they are using. It is a common scenario, but using a Microsoft account with it is not recommended: • Microsoft does not recommend using a shared Microsoft account (that is, one account per classroom). This scenario most likely violates COPPA, and it certainly violates the privacy statements in the Terms of Use for Microsoft accounts. Students using one device can affect students using other devices because of setting synchronization and the shared SkyDrive. • Microsoft does not recommend allowing students to use their own Microsoft accounts in this scenario. Unless they pull the same device from the same cart every time, the first sign-in experience will take up much of the classroom time. In addition, there is no way for schools to manage these accounts for students, and account creation requires parental consent for students under 13 years of age. Instead, Microsoft recommends that you configure a local Windows account on each device. In the schools observed, the most common solution was to create a local user account based on the computer name, and then configure the device to sign in to the desktop automatically. (You can use netplwiz.cpl to configure automatic sign-in, and the sample scripts in this guide configure automatic sign-in during the configuration process.) After students get to the desktop, they can use Internet Explorer to access the Internet, use the many Windows Store apps that do not require Microsoft accounts, or even access virtual desktop infrastructures (VDIs). Of course, they can DEPLOYING WINDOWS RT 8.1 5
  • 8. use their organizational account to access Office 365 or their domain account to access network resources. Importantly, the local Windows account that you create on each device should be a standard user account (least-privileged access), not an administrator account. Schools tend to want to use local Group Policy to completely lock down the device (e.g., remove access to Control Panel, restrict access to the Registry Editor, prevent access to the file system). This extra burden is largely unnecessary and can limit administrators’ ability to maintain and support the device later. You cannot target local Group Policy on Windows RT devices like you can with domain-based Group Policy, so policies you define will affect administrators as well as students. As much as possible, schools should allow the standard user account to do its job to prevent students from making unwanted changes to the device. Standard users cannot change most system settings and cannot change files in system folders. In shared-device scenarios, students should be made to understand that any file they save on a local device might not be available later. Using local Windows accounts does come with baggage. First, you must disable credential caching (for example, Remember Me) on these devices so that students do not inadvertently leave their credentials on shared devices. (See the section, “Local Group Policy settings” on page 45, for settings you can enable to prevent credential caching.) Second, how do you identify who is actually using the device? The most common way is to require students to sign in to the network filter by using their domain credentials. (See the section, “Network filtering recommendations” on page 44, for more information.) Some functionality will not work in this scenario: • Users cannot purchase or install apps from the Windows Store without using a Microsoft account to sign in to the Windows Store. (This is not a bad thing in a school environment, either.) To prevent students from using their own accounts to install Windows Store apps, you can use local Group Policy to disable the Windows Store app. (For more information, see the section, “Local Group Policy settings” on page 45.) • Some apps do not work without a Microsoft account. Which apps do depends on the app. For example, the Bing app works, but the Mail app does not. Test any apps you require for the classroom to determine whether they are compatible with this scenario. • Users cannot access their SkyDrive, and their settings do not synchronize. Students with access to Office 365 can use SkyDrive Pro to make their files available on each shared device they use. The deployment process for this scenario can require significant interaction. Installers must complete the OOBE on each device, but the OOBE will not be repeated when students power on the device. Instead, the device is ready to place in a classroom (or cart) for student use. DEPLOYING WINDOWS RT 8.1 6
  • 9. Prior to beginning device configuration, prepare the configuration store by customizing the scripts provided with this guide and stocking the store with the required source files. The section, “Creating the configuration store” on page 9, describes this step in detail. The high-level deployment process for the shared-device scenario is as follows: 1. Remove the device from its box, and record its serial number. 2. Start the device, and complete the OOBE. You can use a local or Microsoft account as the administrator. Microsoft recommends that you use Microsoft accounts to prepare devices, though, so you can centralize their passwords and install apps from the Windows Store. Keep in mind that Microsoft accounts can install Windows Store apps on up to 81 devices (depending on the app), so if you use Microsoft accounts to configure shared devices, you will need to use multiple accounts. You might consider using one account per classroom, grade level, or even school. 3. Run the configuration script that the section “Preparing shared devices for delivery” on page 26 describes to configure the device. 4. Shut down the device, and deliver it to the cart or classroom. One-to-one scenarios In a one-to-one scenario, students use dedicated Windows RT devices. Those devices might be student or institution owned. This guide assumes they are school owned. In this scenario, this guide recommends that students use Microsoft accounts to sign in to their devices so that they can have the full Windows RT experience. Like the shared-devices scenario, students can use their Microsoft account along with their organizational accounts to access subscription services like Office 365 and their domain accounts to access network resources, such as network shares, VDI, and so on. Unlike the shared-device scenario, students will be administrators on their personal devices. DEPLOYING WINDOWS RT 8.1 NOTE Forcing students to use local Windows accounts with least-privileged access is difficult but not impossible in oneto-one scenarios. The process is identical to the shared-device scenario, but limiting Windows RT devices in this way diminishes their usefulness to students in one-to-one scenarios. 7
  • 10. The deployment process for this scenario requires less interaction and time than the shared-device scenario. You skip the OOBE experience. When you deliver the device to the student and they turn it on, they experience the normal OOBE, but the device will contain your customizations. (The shared-device scenario does not repeat the OOBE.) Prior to beginning device configuration, prepare the configuration store by customizing the scripts provided with this guide and stocking the store with the required source files. The section, “Creating the configuration store” on page 9, describes this step in detail. The high-level deployment process for the one-to-one scenario is as follows: 1. Remove the device from its box, and record its serial number. 2. Start the device in Audit mode to automatically sign in to it as the local administrator. 3. Run the configuration script that the section “Preparing personal devices for delivery” on page 33 describes to configure the device. After the script finishes configuring the device, it runs Sysprep to prepare the device for delivery to the student and shut it down. NOTE By design, the local administrator account cannot run Windows Store apps. 4. Deliver the device to the student. When the student turns on the device, the OOBE starts. The section, “Preparing personal devices for delivery” on page 33, describes this process in step-by-step detail, including how to start the device in Audit mode, plus sample script listings. DEPLOYING WINDOWS RT 8.1 8
  • 11. Creating the configuration store The configuration store is where you store the source files and scripts that configure each device. Use the same configuration store for both deployment scenarios. You can locate the configuration store on a USB flash drive or a network share. (You can also keep a master copy of the configuration store on a network share and copy it to USB flash drives to expedite configuration for each installer.) This guide assumes that the configuration store is on a USB flash drive in D:Store. By default, the scripts in this guide look for files in the following subfolders: Apps  Windows Store apps to sideload on devices Profiles  Wireless networking profiles to add to devices Files  Extra files to copy to devices WARNING The scripts and source files contain passwords in plain text—for example, the password to use for shared accounts, wireless network passphrases, and the credentials under which to run scheduled tasks. Therefore, you must ensure that students do not have access to the configuration store. Scripts  Scripts required to configure devices Logs  Target location in which to Settings  REG files to import into log devices’ names, media access devices’ registries control (MAC) addresses, and Tasks  Scheduled tasks to import serial numbers on devices Policies  Local Group Policy Updates  Update packages settings to copy to devices (MSU files) to install on devices If you store the configuration store on a network share, guest access must be enabled on the configuration store. Otherwise, installers must provide domain credentials when preparing devices. Enabling guest access on the configuration store helps streamline the process. Because Microsoft recommends guest access for the configuration store, Microsoft also recommends creating it on a stand-alone server or PC in the lab, which you can take down after you are done. A laptop or network-attached storage device is perfect for this purpose. The following subsections tackle individual folders in the configuration store separately, including the sample scripts that drive each. The sections, “Preparing shared devices for delivery” on page 26 and “Preparing personal devices for delivery” on page 33, give end-to-end examples that tie everything together. DEPLOYING WINDOWS RT 8.1 NOTE The scripts that this guide provides are samples. Schools must customize and test these scripts prior to using them in any Windows RT device deployment. Although Microsoft has tested these scripts and they do work properly, they are not suitable for use as-is without careful consideration. 9
  • 12. Apps Installing apps from the Windows Store requires a Microsoft account. If you are not using Microsoft accounts (for example, you are deploying shared devices), an alternative is to sideload apps. Sideloading an app means installing it directly on the device without buying it from the Windows Store. For more information, see the article, “Windows RT in the Enterprise,” at http:// technet.microsoft.com/en-us/windows/dn260720.aspx in the Microsoft TechNet library. You need the apps’ package files to sideload them. Package files are files with the .appx file extension, and you obtain them from the apps’ developers. Keep in mind that few developers provide package files for their apps outside of the Windows Store, but if you have an arrangement to sideload developers’ apps or your school has developed Windows Store apps internally, copy the package files they provide to the Apps subfolder of the configuration store. The script in Listing 1 provisions each app in the given path on the target device, meaning that those apps will be available for all users who sign in to the device. NOTE  Sideloading apps on Windows RT devices requires that you first install a sideloading product key. Contact your account team about acquiring sideloading product keys if you must sideload apps. Listing 1  Apply-AppxPackages.ps1 function Apply-AppxPackages { # Install each Windows Store app from the configuration store. # Make sure the Group Policy setting AllowAllTrustedApps is enabled # and a sideloading product key is installed on the device. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing Windows Store app (APPX) packages”)][string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $AppPackages = Get-ChildItem -Filter *.appx $PackageCount = ($AppPackages | Measure-Object).Count Write-Output “Installing ($PackageCount) apps from the configuration store.” $AppPackages | ForEach-Object { Write-Output “...$_” Add-AppxProvisionedPackage -Online -PackagePath $_ -SkipLicense } Pop-Location Write-Output “Finished installing app packages on the device.” DEPLOYING WINDOWS RT 8.1 10
  • 13. } } else { Write-Output “Skipping Windows Store apps because path was not found.” } Files The script in Listing 2 has a simple but useful role. It replicates the contents of the Files subfolder in the configuration store to the target device. To prepare the Files subfolder in the configuration store, create the file and folder structure you want to replicate on the target device. Imagine that the Files subfolder of the configuration store is the root of the system drive on the target device. For example, if you create a text file named helloworld.txt in FilesUsersPublicDesktop, the script in Listing 2 copies that file to the public desktop on each device it runs. The script retains file attributes and overwrites system, read-only, and hidden files. Listing 2  Apply-LocalFiles.ps1 function Apply-LocalFiles { # Copy files and folders from the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing folders and files to copy”)][string] $Path, [Parameter(Mandatory=$true, HelpMessage = ` “Target path to which to copy the source folders and files”)][string] $Target ) } if ((Test-Path -Path $Path -PathType Container)) { Write-Output “Applying files and folders to this device.” xcopy.exe $Path*.* $Target*.* /s /d /e /h /r /k /y ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Write-Output “Finished applying files and folders to this device.” } else { Write-Output “Skipping local files because path was not found.” } Logs Some schools need to collect the MAC address of each Windows RT device as they configure it. For example, schools that have network filters might prefer to use MAC security filtering rather than requiring students to provide their domain credentials to get through the firewall. Collecting the name and MAC address of each device during installation helps simplify the configuration of MAC security filtering. DEPLOYING WINDOWS RT 8.1 11
  • 14. The script in Listing 3 logs the computer name, its MAC address, and its serial number in the Logs subfolder of the configuration store. Because you might have multiple installers setting up devices, this script creates a separate text file for each device to avoid multiuser conflicts if you are storing them in a network share. The file name is the MAC address appended to the computer name. The text file contains the name, MAC address, and serial number separated by commas. Not only does this approach prevent multiuser collisions, it enables you to easily import the comma-delimited text files in to a Microsoft Excel spreadsheet to aggregate them. NOTE  You can customize Listing 3 to collect additional information about devices. Listing 3  Log-DeviceWithMac.ps1 Function Log-DeviceWithMac { # Create a file containing the computer name, MAC address # of the first Wi-Fi adapter, and the device’s serial number. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path in which to log the computer’s name, MAC address, and serial number”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Write-Output “Logging the computer name and MAC address in the configuration store.” $FileName = $env:ComputerName + “_” + ` $((Get-NetAdapter -Name “Wi-FI”).MacAddress ) + “.txt” $FullFilePath = Join-Path $Path $FileName # Check if the file exists do not write a new file, otherwise write the file. If (!(Test-Path $FullFilePath)) { $Content = $env:ComputerName + “, “ + ` $((Get-NetAdapter -Name “Wi-FI”).MacAddress ) + “, “ + ` (Get-WmiObject -Class Win32_BIOS).SerialNumber Add-Content -Path $FullFilePath -Value $Content Write-Output “...$Content” } Write-Output ` “Finished logging the computer name and MAC address in the configuration store.” } } else { Write-Output “Did not log the device because path was not found.” } DEPLOYING WINDOWS RT 8.1 12
  • 15. Policies Windows RT devices do not support domain join, so they do not support domain-based Group Policy. These devices do support local Group Policy, though, and you can create a local Group Policy configuration that you can apply to many devices. The procedure is as follows: 1. On a reference device, configure local Group Policy. 2. Copy the local Group Policy from the reference device to the configuration store. NOTE See the section, “Local Group Policy settings” on page 45, for a list of settings that you might explore for your school’s devices. To learn more about local Group Policy, see http://www.microsoft. com/grouppolicy. 3. Apply the local Group Policy from the configuration store to each device. By default, Group Policy is not enabled on Windows RT devices. You must enable it by starting the Group Policy service (GPSVC). Although you can do this by using the Services console (see the article, “Local Group Policy support for Windows RT,” at http://technet.microsoft. com/en-us/library/2e7bfa32-9fa9-4031-8160-d3a8c526df8d#BKMK_ WinRT in the TechNet library), the script in Listing 4 demonstrates how to enable the Group Policy service by using Windows PowerShell. If you configure a policy and it seems to have no effect on the system, make sure that you have enabled the Group Policy service. Listing 4  Enable-GroupPolicy.ps1 function Enable-GroupPolicy { # Enable and start the Group Policy service. } Set-Service -Name gpsvc -StartupType auto Start-Service -Name gpsvc To configure policies on a reference device, use the Local Group Policy Editor. To access it, type gpedit.msc on the Start screen, and then press Enter. You can configure security policy and Administrative Templates for both the computer and users. Examine each policy’s description to determine whether it supports Windows RT devices. You can also filter settings in Administrative Templates to show only those policies that Windows RT 8.1 devices support. For detailed step-by-step instructions, see the article, “Local Group Policy Editor, at DEPLOYING WINDOWS RT 8.1 13
  • 16. http://technet.microsoft.com/en-us/library/cc725970.aspx in the TechNet library. Thoroughly test each policy to ensure that it works as expected on your devices. The section, “Local Group Policy settings” on page 45, lists many policies interesting to schools deploying Windows RT devices. After you have configured policies on the reference device, copy them from the reference device to the configuration store. The script in Listing 5 is an example. (If the configuration store is on a network share, you must connect to the configuration store by using an account that can write to it.) This script uses the command-line tool Secedit.exe to export the device’s security configuration to an INF file (see the article, “Secedit,” http://technet.microsoft.com/en-us/library/hh875548.aspx in the TechNet library). It also uses the Export-StartLayout Windows PowerShell cmdlet to export the current Start screen layout to an XML file. The script stores both files in the local Group Policy object (GPO—i.e., %SystemRoot%System32GroupPolicy). Then, it copies the local GPO from the reference device to the configuration store. Listing 5  Gather-GroupPolicy.ps1 function Gather-GroupPolicy { # Capture local Group Policy and save in the configuration store. # # Important: Make sure that the path and file name of $StartLayoutFile # is the same as used in the Start Menu Layout Group Policy setting. # By default, these scripts create the file layout.xml in the path # C:WindowsSystem32GroupPolicy. For more information, see # “Deploying Windows RT 8.1 in education.” param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path to the folder in which to store the local Group Policy object”)] ` [string] $Path ) $PolicySource = “C:WindowsSystem32GroupPolicy” $SecurityInfFile = Join-Path $PolicySource “security.inf” $StartLayoutFile = Join-Path $PolicySource “layout.xml” Write-Output “Gathering Group Policy settings to $Path.” secedit /export /cfg $SecurityInfFile | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Export-StartLayout –path $StartLayoutFile –as XML xcopy $PolicySource*.* $Path*.* /s /d /h /r /y | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } } Write-Output “Finished gathering Group Policy settings to $Path” The script in Listing 6 on page 15 reverses the process. It copies the local GPO from the configuration store to the target device, then it uses Secedit to import security policy from the DEPLOYING WINDOWS RT 8.1 14
  • 17. local GPO (i.e., %SystemRoot%System32GroupPolicy). Finally, it configures and starts the Group Policy service and runs Gpupdate.exe to refresh Group Policy on the device. Notice that Listing 6 does not import the Start screen layout. Instead, the layout file is stored within the local GPO, and you must define the policy setting named Start Screen Layout using the path to the layout file (i.e., %SystemRoot%System32GroupPolicylayout.xml). Windows RT 8.1 does support this policy, but it works only if sideloading is enabled on the device. For more information about managing the Start screen layout, see the article, “Customize Windows 8.1 Start Screens by Using Group Policy,” at http://technet.microsoft.com/en-us/library/dn467928.aspx in the TechNet library. Listing 6  Apply-GroupPolicy.ps1 function Apply-GroupPolicy { # Apply local Group Policy settings from A configuration store # to the local computer, and start the Group Policy service. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing the local Group Policy object to copy”)] ` [string] $Path ) $Target = “C:WindowsSystem32GroupPolicy” $SecurityInfPath = Join-Path $Target “security.inf” $SecuritySdbPath = Join-Path $Target “secedit.sdb” if ((Test-Path -Path $Path -PathType Container)) { Write-Output “Configuring Group Policy on this device.” Write-Output “...Copying policy settings to the device.” xcopy $Path*.* $Target*.* /s /d /h /r /y | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Write-Output “...Configuring security policy on the device.” secedit /configure /db $SecuritySdbPath /cfg $SecurityInfPath | Out-Null Write-Output “...Enabling and starting the Group Policy service.” Enable-GroupPolicy Write-Output “...Updating Group Policy on the device.” gpupdate /force | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } } Write-Output “Finished configuring Group Policy on the device.” } else { Write-Output “Skipping Group Policy because path was not found.” } DEPLOYING WINDOWS RT 8.1 15
  • 18. Profiles The Profiles folder of the configuration store contains wireless networking profiles. The process is as follows: 1. On a reference device, connect to each wireless network. 2. Use the example script in Listing 7 to create a wireless network profile for each connection in the configuration store. The script creates one XML file for each profile. 3. Use the example script in Listing 8 to add each wireless network profile in the Profiles folder to the Windows RT device. On devices that have a single wireless interface, such as the Surface, Windows RT will automatically connect to network automatically. Listing 7  Gather-WirelessProfiles.ps1 function Gather-WirelessProfiles { # Export all wireless profiles on the device to the given $Path. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path to the folder in which to store wireless profiles”)][string] $Path ) if (!(Test-Path $Path)) { throw “Unable to export wireless profiles. $Path was not found.” } Write-Output “Gathering wireless profiles to $Path.” netsh.exe wlan export profile folder=”$Path” key=clear ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } } Write-Output “Finished gathering wireless profiles to $Path.” Listing 8  Apply-WirelessProfiles.ps1 function Apply-WirelessProfiles { # Import each wireless profile found in the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing wireless profiles to add to the device”)] ` [string] $Path, [Parameter(Mandatory=$true, HelpMessage = ` “Name of the interface with which to associate the wireless profiles”)] ` [string] $Interface DEPLOYING WINDOWS RT 8.1 16
  • 19. ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $Profiles = Get-ChildItem -Filter *.xml $ProfilesCount = ($Profiles | Measure-Object).Count Write-Output “Importing ($ProfilesCount) wireless profiles from the configuration store.” $Profiles | ForEach-Object { Write-Output “...$_” } netsh.exe wlan add profile filename=$_ interface=$Interface ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Pop-Location Write-Output “Finished importing wireless profiles from the configuration store.” } } else { Write-Output “Skipping wireless profiles because path was not found.” } Settings Like any recent version of Windows, Windows RT stores system and user settings in the registry. You can export registry settings from the registry to REG files. After editing them so that they contain only the settings you want to deploy, store them in the Settings subfolder of the configuration store. NOTE  If you are not familiar with the Windows registry, see the article,” About the Registry,” at http://msdn.microsoft.com/en-us/library/windows/desktop/ms724182(v=vs.85).aspx in the MSDN library before adding REG files to the configuration store. You must understand how to create REG files that contain only the settings you want to deploy. The script in Listing 9 imports each REG file it finds in the configuration store’s Settings folder into the target device’s registry. This is an easy way to configure system and user settings that you cannot configure through local Group Policy. Listing 9  Apply-RegFiles.ps1 function Apply-RegFiles { # Import each registry file found in the configuration store. DEPLOYING WINDOWS RT 8.1 17
  • 20. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing registry (REG) files to import on the device”)]` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $RegFiles = Get-ChildItem -Filter *.reg $RegFileCount = ($RegFiles | Measure-Object).Count Write-Output “Importing ($RegFileCount) REG files from the configuration store.” $RegFiles | ForEach-Object { Write-Output “...$_” reg import $_ | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } } Pop-Location Write-Output “Finished importing REG files from the configuration store.” } } else { Write-Output “Skipping settings because path was not found.” } Tasks Schools can use Windows Intune with or without Microsoft System Center 2012 R2 Configuration Manager to manage Windows RT devices by using Mobile Device Management (MDM), but they cannot use Windows Intune to run Windows PowerShell scripts on remote devices. Although Windows Intune does support a subset of local Group Policy settings that it uses to manage compliance (e.g., Windows Update schedule, password policy, and so on), it does not support configuration of arbitrary local Group Policy settings. A simple workaround is to schedule a task on each device that downloads and runs a script from the school’s network once each day. Then, you can update the script as necessary to at least have some capability to touch Windows RT devices. You can also schedule a task that downloads the local GPO from the configuration store once each day, allowing you to update the local GPOs beyond initial delivery. Listing 10 and Listing 11 on page 19 are examples. Schedule Listing 10, which is a batch script that runs the Windows PowerShell script in Listing 11, bypassing execution policy. Listing 10  Update-DeviceConfig.cmd @echo off rem Update-DeviceConfig.cmd DEPLOYING WINDOWS RT 8.1 18
  • 21. rem rem Start Update-DeviceConfig.ps1, bypassing execution policy. powershell.exe -ExecutionPolicy Bypass ^ %~dp0Update-DeviceConfig.ps1 -PoliciesPath D:StorePolicies Listing 11  Update-DeviceConfig.ps1 # # # # # # # # Update-DeviceConfig.ps1 This is a sample script that you can run from a scheduled task on each Windows RT device. Use this script to touch remote devices when they phone home on schedule. Place it in a network share, which your scheduled task can access, so that you can update it in the future. See the guide “Deploying Windows RT 8.1 in education” for more information about using and customizing this script to configure Windows RT devices in schools. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path to the folder containing the local Group Policy object to copy”)] ` [string] $PoliciesPath ) $ErrorActionPreference = ‘Stop’ # GLOBAL VARIABLES ############################################## $PolicyTarget = “C:WindowsSystem32GroupPolicy” # DO NOT CHANGE # If you change the following folder and file names, you must also change them in # Apply-SharedConfig.pst, Apply-PersonalConfig.pst, and Update-DeviceConfig.pst. $SecurityInfFile = Join-Path $PolicyTarget “security.inf” $SecuritySdbFile = Join-Path $PolicyTarget “secedit.sdb” # MAIN ########################################################## # Update Group Policy on the device. xcopy $PoliciesPath*.* $PolicyTarget*.* /s /d /h /r /y | Out-Null secedit /configure /db $SecuritySdbFile /cfg $SecurityInfFile | Out-Null gpupdate /force | Out-Null The process is as follows: 1. On a reference device, configure each task that you want to schedule. Check the actions, triggers, and settings carefully. Microsoft recommends that you configure a random delay on any task that accesses the network to prevent all of your devices from hitting it at the same time. Of course, test your tasks to make sure they work as expected. 2. Export each task definition to an XML file in the Tasks subfolder of the configuration store. In Task Scheduler, click the task you want to export; then, click Export in the Actions pane. 3. On each target device, import the task definitions from the configuration store. DEPLOYING WINDOWS RT 8.1 19
  • 22. Listing 12 imports each XML file it finds in the Tasks subfolder of the configuration store on the device. In addition to the path, it requires the user name and password of an account under which to run the task. Listing 12 creates that account on the local device and adds it to the local Administrators group. Listing 12  Import-ScheduledTasks.ps1 function Import-ScheduledTasks { # Install each task found in the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing task (XML) files to import into scheduled tasks”)]` [string] $Path, [Parameter(Mandatory=$true, HelpMessage = ` “Name of the account under which to run each imported scheduled task”)]` [string] $TaskUser, [Parameter(Mandatory=$true, HelpMessage = ` “Password for the account under which to run each imported scheduled task”)]` [string] $TaskPassword ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path # Create the local administrator account to use for running the tasks. Write-Output “Creating the local administrator account for $TaskUser.” net user $TaskUser $TaskPassword /add /expires:never /passwordchg:no ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } net localgroup “Administrators” $TaskUser /add ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } # Add each task file to the task scheduler, using our local administrator account. $TaskFiles = Get-ChildItem -Filter *.xml $TaskFileCount = ($TaskFiles | Measure-Object).Count Write-Output “Importing ($TaskFileCount) scheduled tasks from the configuration store.” $TaskFiles | ForEach-Object { Write-Output “...$_” $TaskXML = get-content $_ | Out-String Register-ScheduledTask -Xml $TaskXML -TaskName $_ ` -User $TaskUser -Password $TaskPassword } Pop-Location Write-Output “Finished importing scheduled tasks from the configuration store.” } else { Write-Output “Skipping tasks because path was not found.” } DEPLOYING WINDOWS RT 8.1 20
  • 23. } Updates Windows RT downloads updates over the Internet directly from Microsoft. It does not support Windows Server Update Services (WSUS), and an update catalog is not available for Windows RT. For updates that you absolutely must install during preparation (e.g., updates on which your apps have a dependency), contact your account team to see whether they can provide update packages (MSU files). (For more information about update packages, see the article, “Description of the windows Update Standalone Installer in Windows,” at http://support.microsoft.com/kb/934307 on the Microsoft Support website.) Put each MSU file your account team provides in the Updates folder in the configuration store. The script in Listing 13 automatically installs each update package that it finds in the Updates folder by using the command-line tool Wusa.exe. Listing 13  Apply-UpdateFiles.ps1 function Apply-UpdateFiles { # Install each update found in the configuration store. Windows RT does # not support WSUS and an update catalog is not available. Contact your # account team about acquiring update packages (MSU files). param ( [Parameter(Mandatory=$true, HelpMessage = ` “Folder containing Microsoft update (MSU) files to install on the device”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $UpdatePackages = Get-ChildItem -Filter *.msu $PackageCount = ($UpdatePackages | Measure-Object).Count Write-Output “Installing ($PackageCount) updates from the configuration store.” $UpdatePackages | ForEach-Object { Write-Output “...$_” $cmd = “wusa $_ /quiet /norestart” Invoke-Expression $cmd # Wait until the process finishes before continuing. } while ((Get-Process | Where { $_.Name -eq ‘wusa’}) -ne $null) { Start-Sleep -Seconds 1 } Pop-Location Write-Output “Finished installing update packages on the device.” } } else { Write-Output “Skipping update packages because path was not found.” } DEPLOYING WINDOWS RT 8.1 21
  • 24. Users In shared-device scenarios, you must create a local account for students to use, but what do you name this account? You can use the same name for the account on every device, but a common alternative is to base the name of the shared user account on the computer, removing any special characters, like dashes. The script in Listing 14 shows an example that creates a local user account based on the computer name. You can easily modify this script to use any other convention, though. As a bonus, this script also demonstrates how to configure the device so that it automatically signs in by using the shared user account to help students get to the desktop quicker. Alternatively, you can use the netplwiz.cpl Control Panel applet to configure automatic sign-in. NOTE  The script in Listing 14 uses NET USER to add the shared user account, and it uses the command-line option /expires:never to disable password expiration for the account. In shared-device scenarios, this is necessary to prevent mayhem when devices are distributed in classrooms. However, schools using an MDM service must understand that this option breaks password management in these services. Listing 14  Create-SharedUser.ps1 function Create-SharedUser { # Provision a shared local account based on the device’s name. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Password to use for the device’s shared user account”)][string] $Password ) $LocalUserName = $env:ComputerName -replace “-”, “” Write-Output “Creating the local user account $LocalUserName.” # # # # Use NET USER to add the shared account to this device. This script disables password expiration for the shared user account, which is necessary in shared-device scenarios. However, this will break password management in Mobile Device Management. net user $LocalUserName $Password /add /expires:never /passwordchg:no ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Write-Output “Configuring device to automatically sign in as $LocalUserName.” Set-ItemProperty ` -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon” ` -Name DefaultDomainName -Value $env:ComputerName | Out-Null DEPLOYING WINDOWS RT 8.1 22
  • 25. Set-ItemProperty -` Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon” ` -Name DefaultUserName -Value $LocalUserName | Out-Null New-ItemProperty ` -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon” ` -Name DefaultPassword -Value $Password | Out-Null Set-ItemProperty ` -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon” ` -Name AutoAdminLogon -Value “1” | Out-Null } Write-Output “Finished creating the local user account on the device.” DEPLOYING WINDOWS RT 8.1 23
  • 26. Building a complete solution The sample scripts in “Creating the configuration store” showed how to solve individual problems, such as applying updates or scheduling tasks. The scripts in this section combine everything into a complete solution, including scripts to stock the configuration store and apply shared and personal configurations. You must stock most of the files in the configuration store manually. Copy APPX files to the Apps subfolder, MSU files to the Updates subfolder, and so on. However, Listing 15 and Listing 16 automatically copy local Group Policy settings and wireless networking profiles from the reference device to the configuration store. Listing 15 is a batch script that runs the similarly named Windows PowerShell script while bypassing execution policy, preventing installers from having to set execution policy to unrestricted on each device they configure. Store both scripts in the Scripts subfolder of the configuration store so that you can access them from any reference device. You specify the path to the configuration store in the last line of Listing 15. Listing 15  Gather-DeviceConfig.cmd @echo off rem Gather-DeviceConfig.cmd rem rem Start Gather-DeviceConfig.ps1, bypassing execution policy. powershell.exe -ExecutionPolicy Bypass ^ %~dp0Gather-DeviceConfig.ps1 -StorePath D:Store Listing 16  Gather-DeviceConfig.ps1 # # # # # # Gather-DeviceConfig.ps1 Gather configuration from reference device and save in the configuration store. The configuration store can be on a USB flash drive or a network share. See the guide “Deploying Windows RT 8.1 in education” for more information about using and customizing this script to configure Windows RT devices in schools. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path to the folder containing the configuration store”)][string] $StorePath ) $ErrorActionPreference = ‘Stop’ if (!(Test-Path -Path $StorePath -PathType Container)) { throw “$StorePath was not found.” } # GLOBAL VARIABLES ############################################## # If you change the following folder and file names, you must also change them in DEPLOYING WINDOWS RT 8.1 24
  • 27. # Apply-SharedConfig.pst, Apply-PersonalConfig.pst, and Update-DeviceConfig.pst. $PoliciesPath = Join-Path $StorePath “Policies” $ProfilesPath = Join-Path $StorePath “Profiles” # FUNCTIONS ##################################################### function Gather-WirelessProfiles { # Export all wireless profiles on the device to the given $Path. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path to the folder in which to store wireless profiles”)][string] $Path ) if (!(Test-Path $Path)) { throw “Unable to export wireless profiles. $Path was not found.” } Write-Output “Gathering wireless profiles to $Path.” netsh.exe wlan export profile folder=”$Path” key=clear ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } } Write-Output “Finished gathering wireless profiles to $Path.” function Gather-GroupPolicy { # Capture local Group Policy and save in the configuration store. # # Important: Make sure that the path and file name of $StartLayoutFile # is the same as used in the Start Menu Layout Group Policy setting. # By default, these scripts create the file layout.xml in the path # C:WindowsSystem32GroupPolicy. For more information, see # “Deploying Windows RT 8.1 in education.” param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path to the folder in which to store the local Group Policy object”)] ` [string] $Path ) $PolicySource = “C:WindowsSystem32GroupPolicy” $SecurityInfFile = Join-Path $PolicySource “security.inf” $StartLayoutFile = Join-Path $PolicySource “layout.xml” Write-Output “Gathering Group Policy settings to $Path.” secedit /export /cfg $SecurityInfFile | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Export-StartLayout –path $StartLayoutFile –as XML xcopy $PolicySource*.* $Path*.* /s /d /h /r /y | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Write-Output “Finished gathering Group Policy settings to $Path” DEPLOYING WINDOWS RT 8.1 25
  • 28. } # MAIN ########################################################## Write-Output “Beginning to gather this device’s configuration.” Write-Output “------------------------------------------------------------------------” Gather-GroupPolicy $PoliciesPath Write-Output “------------------------------------------------------------------------” Gather-WirelessProfiles $ProfilesPath Write-Output “------------------------------------------------------------------------” Write-Output “Finished gathering this device’s configuration.” Preparing shared devices for delivery Similar to the scripts in the previous section, Listing 17 and Listing 18 are complete examples that rely on the examples you learned about in the section, “Creating the configuration store” on page 9. Listing 17 runs the Windows PowerShell script in Listing 18 while bypassing execution policy. Listing 18 is a working example that applies the contents of the previously prepared configuration store to the target device. Store both scripts in the Scripts subfolder of the configuration store so that you can access them from any target device. You specify the path to the configuration store in the last line of Listing 17. In shared-device scenarios, the preparation process is as follows: 1. Start the device, and complete the OOBE. 2. At an elevated command prompt, run the code Listing 17, which launches the Windows PowerShell script in Listing 18 while bypassing execution policy. 3. Perform any manual steps required to configure the device (e.g., installing Windows Store apps). 4. Shut down the device, and deliver it to the classroom. Listing 17  Apply-SharedConfig.cmd @echo off rem Apply-SharedConfig.cmd rem rem Start Apply-SharedConfig.ps1, bypassing execution policy. powershell.exe -ExecutionPolicy Bypass ^ %~dp0Apply-SharedConfig.ps1 -StorePath D:Store Listing 18  Apply-SharedConfig.ps1 # Apply-SharedConfig.ps1 # # Apply settings from the configuration store to the local device. DEPLOYING WINDOWS RT 8.1 26
  • 29. # # # # This script configures shared devices. See Apply-PersonalConfig.ps1 for a script that prepares devices for one-to-one scenarios. See the guide “Deploying Windows RT 8.1 in education” for more information about using and customizing this script to configure Windows RT devices in schools. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path to the folder containing the configuration store”)][string] $StorePath ) $ErrorActionPreference = ‘Stop’ if (!(Test-Path -Path $StorePath -PathType Container)) { throw “$StorePath was not found.” } # GLOBAL VARIABLES ############################################## # # # # # # The following variables define subfolder names within the configuration store. These scripts expect specific types of files to appear in specific subfolders. If you change the following folder and file names, you must also change them in Gather-DeviceConfig.pst, Apply-PersonalConfig.pst, and Update-DeviceConfig.pst. $AppsPath $FilesPath $LogsPath $PoliciesPath $ProfilesPath $SettingsPath $TasksPath $UpdatesPath # # # # = = = = Join-Path $StorePath “Apps” Join-Path $StorePath “Files” Join-Path $StorePath “Logs” Join-Path $StorePath “Policies” = Join-Path $StorePath “Profiles” = Join-Path $StorePath “Settings” = Join-Path $StorePath “Tasks” = Join-Path $StorePath “Updates” The following variables define the user name and password to use to create scheduled tasks on each device. The scripts will add this account to the local device and use it when creating each scheduled task. $TaskUser $TaskPassword = “DevAdmin” = “Passw0rd” # Additional variables: $Interface $UserPassword $FilesTarget = “Wi-Fi” = “Passw0rd” = “C:” # The name of the Wi-Fi interface on Surface devices # The password to use when creating the shared user account # The root of the file system for applying local files. # FUNCTIONS ##################################################### function Apply-AppxPackages { # Install each Windows Store app from the configuration store. # Make sure the Group Policy setting AllowAllTrustedApps is enabled # and a sideloading product key is installed on the device. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing Windows Store app (APPX) packages”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path DEPLOYING WINDOWS RT 8.1 27
  • 30. $AppPackages = Get-ChildItem -Filter *.appx $PackageCount = ($AppPackages | Measure-Object).Count Write-Output “Installing ($PackageCount) apps from the configuration store.” $AppPackages | ForEach-Object { Write-Output “...$_” Add-AppxProvisionedPackage -Online -PackagePath $_ -SkipLicense } Pop-Location Write-Output “Finished installing app packages on the device.” } } else { Write-Output “Skipping Windows Store apps because path was not found.” } function Apply-LocalFiles { # Copy files and folders from the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing folders and files to copy”)][string] $Path, [Parameter(Mandatory=$true, HelpMessage = ` “Target path to which to copy the source folders and files”)][string] $Target ) } if ((Test-Path -Path $Path -PathType Container)) { Write-Output “Applying files and folders to this device.” xcopy.exe $Path*.* $Target*.* /s /d /e /h /r /k /y ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Write-Output “Finished applying files and folders to this device.” } else { Write-Output “Skipping local files because path was not found.” } Function Log-DeviceWithMac { # Create a file containing the computer name, MAC address # of the first Wi-Fi adapter, and the device’s serial number. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path in which to log the computer’s name, MAC address, and serial number”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Write-Output “Logging the computer name and MAC address in the configuration store.” $FileName = $env:ComputerName + “_” + ` $((Get-NetAdapter -Name “Wi-FI”).MacAddress ) + “.txt” $FullFilePath = Join-Path $Path $FileName # Check if the file exists do not write a new file, otherwise write the file. DEPLOYING WINDOWS RT 8.1 28
  • 31. If (!(Test-Path $FullFilePath)) { $Content = $env:ComputerName + “, “ + ` $((Get-NetAdapter -Name “Wi-FI”).MacAddress ) + “, “ + ` (Get-WmiObject -Class Win32_BIOS).SerialNumber Add-Content -Path $FullFilePath -Value $Content Write-Output “...$Content” } Write-Output ` “Finished logging the computer name and MAC address in the configuration store.” } } else { Write-Output “Did not log the device because path was not found.” } function Enable-GroupPolicy { # Enable and start the Group Policy service. } Set-Service -Name gpsvc -StartupType auto Start-Service -Name gpsvc function Apply-GroupPolicy { # Apply local Group Policy settings from A configuration store # to the local computer, and start the Group Policy service. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing the local Group Policy object to copy”)] ` [string] $Path ) $Target = “C:WindowsSystem32GroupPolicy” $SecurityInfPath = Join-Path $Target “security.inf” $SecuritySdbPath = Join-Path $Target “secedit.sdb” if ((Test-Path -Path $Path -PathType Container)) { Write-Output “Configuring Group Policy on this device.” Write-Output “...Copying policy settings to the device.” xcopy $Path*.* $Target*.* /s /d /h /r /y | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Write-Output “...Configuring security policy on the device.” secedit /configure /db $SecuritySdbPath /cfg $SecurityInfPath | Out-Null Write-Output “...Enabling and starting the Group Policy service.” Enable-GroupPolicy Write-Output “...Updating Group Policy on the device.” gpupdate /force | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } } Write-Output “Finished configuring Group Policy on the device.” } else { Write-Output “Skipping Group Policy because path was not found.” } DEPLOYING WINDOWS RT 8.1 29
  • 32. function Apply-RegFiles { # Import each registry file found in the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing registry (REG) files to import on the device”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $RegFiles = Get-ChildItem -Filter *.reg $RegFileCount = ($RegFiles | Measure-Object).Count Write-Output “Importing ($RegFileCount) REG files from the configuration store.” $RegFiles | ForEach-Object { Write-Output “...$_” reg import $_ | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } } Pop-Location Write-Output “Finished importing REG files from the configuration store.” } } else { Write-Output “Skipping settings because path was not found.” } function Import-ScheduledTasks { # Install each task found in the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing task (XML) files to import into scheduled tasks”)] ` [string] $Path, [Parameter(Mandatory=$true, HelpMessage = ` “Name of the account under which to run each imported scheduled task”)] ` [string] $TaskUser, [Parameter(Mandatory=$true, HelpMessage = ` “Password for the account under which to run each imported scheduled task”)] ` [string] $TaskPassword ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path # Create the local administrator account to use for running the tasks. Write-Output “Creating the local administrator account for $TaskUser.” net user $TaskUser $TaskPassword /add /expires:never /passwordchg:no ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } net localgroup “Administrators” $TaskUser /add ` | Tee-Object -Variable Results | Out-Null DEPLOYING WINDOWS RT 8.1 30
  • 33. if ($LASTEXITCODE -ne 0) { throw $Results } # Add each task file to the task scheduler, using our local administrator account. $TaskFiles = Get-ChildItem -Filter *.xml $TaskFileCount = ($TaskFiles | Measure-Object).Count Write-Output “Importing ($TaskFileCount) scheduled tasks from the configuration store.” $TaskFiles | ForEach-Object { Write-Output “...$_” $TaskXML = get-content $_ | Out-String Register-ScheduledTask -Xml $TaskXML -TaskName $_ ` -User $TaskUser -Password $TaskPassword } Pop-Location Write-Output “Finished importing scheduled tasks from the configuration store.” } } else { Write-Output “Skipping tasks because path was not found.” } function Apply-UpdateFiles { # Install each update found in the configuration store. Windows RT does # not support WSUS and an update catalog is not available. Contact your # account team about acquiring update packages (MSU files). param ( [Parameter(Mandatory=$true, HelpMessage = ` “Folder containing Microsoft update (MSU) files to install on the device”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $UpdatePackages = Get-ChildItem -Filter *.msu $PackageCount = ($UpdatePackages | Measure-Object).Count Write-Output “Installing ($PackageCount) updates from the configuration store.” $UpdatePackages | ForEach-Object { Write-Output “...$_” $cmd = “wusa $_ /quiet /norestart” Invoke-Expression $cmd # Wait until the process finishes before continuing. } while ((Get-Process | Where { $_.Name -eq ‘wusa’}) -ne $null) { Start-Sleep -Seconds 1 } Pop-Location Write-Output “Finished installing update packages on the device.” } else { Write-Output “Skipping update packages because path was not found.” } DEPLOYING WINDOWS RT 8.1 31
  • 34. } function Create-SharedUser { # Provision a shared local account based on the device’s name. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Password to use for the device’s shared user account”)] ` [string] $Password ) $LocalUserName = $env:ComputerName -replace “-”, “” Write-Output “Creating the local user account $LocalUserName.” # # # # Use NET USER to add the shared account to this device. This script disables password expiration for the shared user account, which is necessary in shared-device scenarios. However, this will break password management in Mobile Device Management. net user $LocalUserName $Password /add /expires:never /passwordchg:no ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Write-Output “Configuring device to automatically sign in as $LocalUserName.” Set-ItemProperty ` -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon” ` -Name DefaultDomainName -Value $env:ComputerName | Out-Null Set-ItemProperty ` -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon” ` -Name DefaultUserName -Value $LocalUserName | Out-Null New-ItemProperty ` -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon” ` -Name DefaultPassword -Value $Password | Out-Null Set-ItemProperty ` -Path “HKLM:SOFTWAREMicrosoftWindows NTCurrentVersionWinlogon” ` -Name AutoAdminLogon -Value “1” | Out-Null } Write-Output “Finished creating the local user account on the device.” function Apply-WirelessProfiles { # Import each wireless profile found in the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing wireless profiles to add to the device”)] ` [string] $Path, [Parameter(Mandatory=$true, HelpMessage = ` “Name of the interface with which to associate the wireless profiles”)] ` [string] $Interface ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $Profiles = Get-ChildItem -Filter *.xml $ProfilesCount = ($Profiles | Measure-Object).Count Write-Output “Importing ($ProfilesCount) wireless profiles from the configuration store.” DEPLOYING WINDOWS RT 8.1 32
  • 35. $Profiles | ForEach-Object { Write-Output “...$_” } netsh.exe wlan add profile filename=$_ interface=$Interface ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Pop-Location Write-Output “Finished importing wireless profiles from the configuration store.” } } else { Write-Output “Skipping wireless profiles because path was not found.” } # MAIN Write-Output “Beginning to configure this device for shared use.” Write-Output “------------------------------------------------------------------------” Apply-WirelessProfiles $ProfilesPath $Interface Write-Output “------------------------------------------------------------------------” Apply-LocalFiles $FilesPath $FilesTarget Write-Output “------------------------------------------------------------------------” Apply-RegFiles $SettingsPath Write-Output “------------------------------------------------------------------------” Apply-GroupPolicy $PoliciesPath Write-Output “------------------------------------------------------------------------” Import-ScheduledTasks $TasksPath $TaskUser $TaskPassword Write-Output “------------------------------------------------------------------------” Apply-UpdateFiles $UpdatesPath Write-Output “------------------------------------------------------------------------” Create-SharedUser $UserPassword Write-Output “------------------------------------------------------------------------” Apply-AppxPackages $AppsPath Write-Output “------------------------------------------------------------------------” Log-DeviceWithMac $LogsPath Write-Output “------------------------------------------------------------------------” Write-Output “Finished configuring this device for shared use.” Preparing personal devices for delivery When preparing personal devices for delivery, you use the same configuration store you used for shared devices. That includes copying the local GPO and wireless networking profiles from a reference device to the configuration store, adding APPX and MSU files, and so on. After you have stocked the configuration store, preparing personal devices for delivery can be easier and a bit quicker than preparing shared devices, mainly because you do not have to complete the OOBE when configuring the device. Instead, you start devices in Audit mode. In Audit mode, you can configure and customize devices prior to delivering them to students. After the first time students start their devices, they see the OOBE. For more information about Audit mode, see the article, “Audit Mode Overview,” at http://technet.microsoft.com/en-us/library/ hh824891.aspx in the TechNet library. DEPLOYING WINDOWS RT 8.1 33
  • 36. To prepare personal devices for delivery, complete the following steps: 1. Start the device, and wait for the OOBE to begin. 2. Tap the Accessibility icon, tap On Screen Keyboard, and then press Ctrl+Shift+Fn+F3 to start the device in Audit mode, signing in to the local Administrator automatically. 3. At an elevated command prompt, run the code in Listing 19, which then launches the code in Listing 20. Because Sysprep cannot finish while restarts are pending, Listing 20 finishes by copying ExitAuditMode.ps1 (Listing 21) and Unattend.xml (Listing 22) to the device and configures the device so that it runs Exit-AuditMode.ps1 the next time the device starts. Exit-AuditMode.ps1 runs Sysprep to reseal the device, exiting Audit mode and shutting the device down. 4. Deliver the device to the student. Listing 19  Apply-PersonalConfig.cmd @echo off rem Apply-PersonalConfig.cmd rem rem Start Apply-PersonalConfig.ps1, bypassing execution policy. powershell.exe -ExecutionPolicy Bypass ^ %~dp0Apply-PersonalConfig.ps1 -StorePath D:Store Listing 20  Apply-PersonalConfig.ps1 # # # # # # # # Apply-PersonalConfig.ps1 Apply settings from the configuration store to the local device, and prepare the device for delivery to the student by running Sysprep. This script configures personal devices. See Apply-SharedConfig.ps1 for a script that prepares devices for shared scenarios. See the guide “Deploying Windows RT 8.1 in education” for more information about using and customizing this script to configure Windows RT devices in schools. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path to the folder containing the configuration store”)][string] $StorePath ) $ErrorActionPreference = ‘Stop’ if (!(Test-Path -Path $StorePath -PathType Container)) { throw “$StorePath was not found.” } # GLOBAL VARIABLES ############################################## $ScriptPath = Split-Path -Parent $MyInvocation.MyCommand.Path # The following variables define subfolder names within DEPLOYING WINDOWS RT 8.1 34
  • 37. # # # # # the configuration store. These scripts expect specific types of files to appear in specific subfolders. If you change the following folder and file names, you must also change them in Gather-DeviceConfig.pst, Apply-PersonalConfig.pst, and Update-DeviceConfig.pst. $AppsPath $FilesPath $LogsPath $PoliciesPath $ProfilesPath $SettingsPath $TasksPath $UpdatesPath # # # # = = = = Join-Path $StorePath “Apps” Join-Path $StorePath “Files” Join-Path $StorePath “Logs” Join-Path $StorePath “Policies” = Join-Path $StorePath “Profiles” = Join-Path $StorePath “Settings” = Join-Path $StorePath “Tasks” = Join-Path $StorePath “Updates” The following variables define the user name and password to use to create scheduled tasks on each device. The scripts will add this account to the local device and use it when creating each scheduled task. $TaskUser $TaskPassword = “DevAdmin” = “Passw0rd” # Additional variables: $Interface $FilesTarget = “Wi-Fi” = “C:” # The name of the Wi-Fi interface on Surface devices # The root of the file system for applying local files. # FUNCTIONS ##################################################### function Apply-AppxPackages { # Install each Windows Store app from the configuration store. # Make sure the Group Policy setting AllowAllTrustedApps is enabled # and a sideloading product key is installed on the device. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing Windows Store app (APPX) packages”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $AppPackages = Get-ChildItem -Filter *.appx $PackageCount = ($AppPackages | Measure-Object).Count Write-Output “Installing ($PackageCount) apps from the configuration store.” $AppPackages | ForEach-Object { Write-Output “...$_” Add-AppxProvisionedPackage -Online -PackagePath $_ -SkipLicense } Pop-Location Write-Output “Finished installing app packages on the device.” } } else { Write-Output “Skipping Windows Store apps because path was not found.” } DEPLOYING WINDOWS RT 8.1 35
  • 38. function Apply-LocalFiles { # Copy files and folders from the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing folders and files to copy”)][string] $Path, [Parameter(Mandatory=$true, HelpMessage = ` “Target path to which to copy the source folders and files”)][string] $Target ) } if ((Test-Path -Path $Path -PathType Container)) { Write-Output “Applying files and folders to this device.” xcopy.exe $Path*.* $Target*.* /s /d /e /h /r /k /y ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Write-Output “Finished applying files and folders to this device.” } else { Write-Output “Skipping local files because path was not found.” } Function Log-DeviceWithMac { # Create a file containing the computer name, MAC address # of the first Wi-Fi adapter, and the device’s serial number. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path in which to log the computer’s name, MAC address, and serial number”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Write-Output “Logging the computer name and MAC address in the configuration store.” $FileName = $env:ComputerName + “_” + ` $((Get-NetAdapter -Name “Wi-FI”).MacAddress ) + “.txt” $FullFilePath = Join-Path $Path $FileName # Check if the file exists do not write a new file, otherwise write the file. If (!(Test-Path $FullFilePath)) { $Content = $env:ComputerName + “, “ + ` $((Get-NetAdapter -Name “Wi-FI”).MacAddress ) + “, “ + ` (Get-WmiObject -Class Win32_BIOS).SerialNumber Add-Content -Path $FullFilePath -Value $Content Write-Output “...$Content” } Write-Output ` “Finished logging the computer name and MAC address in the configuration store.” } } else { Write-Output “Did not log the device because path was not found.” } function Enable-GroupPolicy { # Enable and start the Group Policy service. DEPLOYING WINDOWS RT 8.1 36
  • 39. } Set-Service -Name gpsvc -StartupType auto Start-Service -Name gpsvc function Apply-GroupPolicy { # Apply local Group Policy settings from A configuration store # to the local computer, and start the Group Policy service. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing the local Group Policy object to copy”)] ` [string] $Path ) $Target = “C:WindowsSystem32GroupPolicy” $SecurityInfPath = Join-Path $Target “security.inf” $SecuritySdbPath = Join-Path $Target “secedit.sdb” if ((Test-Path -Path $Path -PathType Container)) { Write-Output “Configuring Group Policy on this device.” Write-Output “...Copying policy settings to the device.” xcopy $Path*.* $Target*.* /s /d /h /r /y | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } # # # # # # For personal configurations, this script does not import the security settings by using secedit. These security settings can interfere with running Sysprep in Audit mode, because they disable the local Administrator account by default. To work around this problem, the script Exit-AuditMode.ps1 imports the security settings just prior to running Sysprep. # Write-Output “...Configuring security policy on the device.” # secedit /configure /db $SecuritySdbPath /cfg $SecurityInfPath | Out-Null Write-Output “...Enabling and starting the Group Policy service.” Enable-GroupPolicy Write-Output “...Updating Group Policy on the device.” gpupdate /force | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } } Write-Output “Finished configuring Group Policy on the device.” } else { Write-Output “Skipping Group Policy because path was not found.” } function Apply-RegFiles { # Import each registry file found in the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing registry (REG) files to import on the device”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { DEPLOYING WINDOWS RT 8.1 37
  • 40. Push-Location -Path $Path $RegFiles = Get-ChildItem -Filter *.reg $RegFileCount = ($RegFiles | Measure-Object).Count Write-Output “Importing ($RegFileCount) REG files from the configuration store.” $RegFiles | ForEach-Object { Write-Output “...$_” reg import $_ | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } } Pop-Location Write-Output “Finished importing REG files from the configuration store.” } } else { Write-Output “Skipping settings because path was not found.” } function Import-ScheduledTasks { # Install each task found in the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing task (XML) files to import into scheduled tasks”)] ` [string] $Path, [Parameter(Mandatory=$true, HelpMessage = ` “Name of the account under which to run each imported scheduled task”)] ` [string] $TaskUser, [Parameter(Mandatory=$true, HelpMessage = ` “Password for the account under which to run each imported scheduled task”)] ` [string] $TaskPassword ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path # Create the local administrator account to use for running the tasks. Write-Output “Creating the local administrator account for $TaskUser.” net user $TaskUser $TaskPassword /add /expires:never /passwordchg:no ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } net localgroup “Administrators” $TaskUser /add ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } # Add each task file to the task scheduler, using our local administrator account. $TaskFiles = Get-ChildItem -Filter *.xml $TaskFileCount = ($TaskFiles | Measure-Object).Count Write-Output “Importing ($TaskFileCount) scheduled tasks from the configuration store.” $TaskFiles | ForEach-Object { DEPLOYING WINDOWS RT 8.1 38
  • 41. } Write-Output “...$_” $TaskXML = get-content $_ | Out-String Register-ScheduledTask -Xml $TaskXML -TaskName $_ ` -User $TaskUser -Password $TaskPassword Pop-Location Write-Output “Finished importing scheduled tasks from the configuration store.” } } else { Write-Output “Skipping tasks because path was not found.” } function Apply-UpdateFiles { # Install each update found in the configuration store. Windows RT does # not support WSUS and an update catalog is not available. Contact your # account team about acquiring update packages (MSU files). param ( [Parameter(Mandatory=$true, HelpMessage = ` “Folder containing Microsoft update (MSU) files to install on the device”)] ` [string] $Path ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $UpdatePackages = Get-ChildItem -Filter *.msu $PackageCount = ($UpdatePackages | Measure-Object).Count Write-Output “Installing ($PackageCount) updates from the configuration store.” $UpdatePackages | ForEach-Object { Write-Output “...$_” $cmd = “wusa $_ /quiet /norestart” Invoke-Expression $cmd # Wait until the process finishes before continuing. } while ((Get-Process | Where { $_.Name -eq ‘wusa’}) -ne $null) { Start-Sleep -Seconds 1 } Pop-Location Write-Output “Finished installing update packages on the device.” } } else { Write-Output “Skipping update packages because path was not found.” } function Apply-WirelessProfiles { # Import each wireless profile found in the configuration store. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing wireless profiles to add to the device”)] ` [string] $Path, [Parameter(Mandatory=$true, HelpMessage = ` “Name of the interface with which to associate the wireless profiles”)] ` DEPLOYING WINDOWS RT 8.1 39
  • 42. [string] $Interface ) if ((Test-Path -Path $Path -PathType Container)) { Push-Location -Path $Path $Profiles = Get-ChildItem -Filter *.xml $ProfilesCount = ($Profiles | Measure-Object).Count Write-Output “Importing ($ProfilesCount) wireless profiles from the configuration store.” $Profiles | ForEach-Object { Write-Output “...$_” } netsh.exe wlan add profile filename=$_ interface=$Interface ` | Tee-Object -Variable Results | Out-Null if ($LASTEXITCODE -ne 0) { throw $Results } Pop-Location Write-Output “Finished importing wireless profiles from the configuration store.” } } else { Write-Output “Skipping wireless profiles because path was not found.” } function Start-Sysprep { # Prepare the device to run Sysprep the next time the device starts. param ( [Parameter(Mandatory=$true, HelpMessage = ` “Path of the folder containing this script and Unattend.xml”)] ` [string] $ScriptPath ) $TargetPath = “C:WindowsPanther” $SaveUnattendFile = “Unattend.sav” $RunOnceSource = Join-Path $ScriptPath Exit-AuditMode.ps1 $RunOnceTarget = Join-Path $TargetPath Exit-AuditMode.ps1 $SourceUnattendFile = Join-Path $ScriptPath Unattend.xml $TargetUnattendFile = Join-Path $TargetPath Unattend.xml # Copy the Unattend.xml file from the configuration store # to the Panther folder on the Windows RT device. if (Test-Path $SourceUnattendFile ) { Write-Output “Copying Unattend.xml to the device.” if (Test-Path $TargetUnattendFile ) { Rename-Item $TargetUnattendFile $SaveUnattendFile } Copy-Item $SourceUnattendFile $TargetUnattendFile } # Prepare the Windows RT device to run Exit-AuditMode.ps1 the # next time the device starts. We use the RunOnce registry key. if (test-path $RunOnceSource ) { Write-Output “Preparing the device to restart.” Copy-Item $RunOnceSource $RunOnceTarget New-ItemProperty ` DEPLOYING WINDOWS RT 8.1 40
  • 43. } } -Path HKLM:SOFTWAREMicrosoftWindowsCurrentVersionRunOnce ` -Name Sysprep ` -Value “powershell.exe -ExecutionPolicy Bypass $RunOnceTarget” | Out-Null # MAIN ########################################################## Write-Output “Beginning to configure this device for personal use.” Write-Output “This process is complete after the device shuts down.” Write-Output “------------------------------------------------------------------------” Apply-WirelessProfiles $ProfilesPath $Interface Write-Output “------------------------------------------------------------------------” Apply-LocalFiles $FilesPath $FilesTarget Write-Output “------------------------------------------------------------------------” Apply-RegFiles $SettingsPath Write-Output “------------------------------------------------------------------------” Apply-GroupPolicy $PoliciesPath Write-Output “------------------------------------------------------------------------” Import-ScheduledTasks $TasksPath $TaskUser $TaskPassword Write-Output “------------------------------------------------------------------------” Apply-UpdateFiles $UpdatesPath Write-Output “------------------------------------------------------------------------” Apply-AppxPackages $AppsPath Write-Output “------------------------------------------------------------------------” Log-DeviceWithMac $LogsPath Write-Output “------------------------------------------------------------------------” Start-Sysprep $ScriptPath shutdown /r /t 0 Listing 21  Exit-AuditMode.ps1 # # # # # # # # Exit-AuditMode.ps1 The script Apply-PersonalConfig.ps1 uses this script to exit Audit mode by running Sysprep. Sysprep cannot run while restarts are pending. Apply-PersonalConfig sets this script to run the next time the device starts, and then restarts the device to clear pending restarts. See the guide “Deploying Windows RT 8.1 in education” for more information about using and customizing this script to configure Windows RT devices in schools. $Target = “C:WindowsSystem32GroupPolicy” $SecurityInfPath = Join-Path $Target “security.inf” $SecuritySdbPath = Join-Path $Target “secedit.sdb” # # # # Run secedit to import the security configuration. This must be done just prior to running Sysprep because the security configuration can interfere with restarting the device in Audit mode, since the default security configuration disables the local Administrator account. secedit /configure /db $SecuritySdbPath /cfg $SecurityInfPath | Out-Null Stop-Process -Name sysprep -ErrorAction SilentlyContinue C:WindowsSystem32SysprepSysprep.exe /oobe /shutdown Listing 22  Unattend.xml <?xml version=”1.0” encoding=”utf-8”?> <unattend xmlns=”urn:schemas-microsoft-com:unattend”> <settings pass=”specialize”> <component name=”Microsoft-Windows-Shell-Setup” processorArchitecture=”arm” publicKeyToken=”31bf3856ad364e35” DEPLOYING WINDOWS RT 8.1 41
  • 44. language=”neutral” versionScope=”nonSxS” xmlns:wcm=”http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”> <ComputerName>Surface</ComputerName> <RegisteredOrganization>Contoso</RegisteredOrganization> <RegisteredOwner>Contoso</RegisteredOwner> <DoNotCleanTaskBar>true</DoNotCleanTaskBar> <TimeZone>Pacific Standard Time</TimeZone> </component> <component name=”Microsoft-Windows-International-Core” processorArchitecture=”arm” publicKeyToken=”31bf3856ad364e35” language=”neutral” versionScope=”nonSxS” xmlns:wcm=”http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”> <InputLocale>0409:00000409</InputLocale> <SystemLocale>en-US</SystemLocale> <UILanguage>en-US</UILanguage> <UserLocale>en-US</UserLocale> </component> <component name=”Security-Malware-Windows-Defender” processorArchitecture=”arm” publicKeyToken=”31bf3856ad364e35” language=”neutral” versionScope=”nonSxS” xmlns:wcm=”http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”> <TrustedImageIdentifier>81b553fb-1321-4862-9269-594e5c04c1f2</TrustedImageIdentifier> </component> </settings> <settings pass=”oobeSystem”> <component name=”Microsoft-Windows-Shell-Setup” processorArchitecture=”arm” publicKeyToken=”31bf3856ad364e35” language=”neutral” versionScope=”nonSxS” xmlns:wcm=”http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”> <OEMInformation> <HelpCustomized>false</HelpCustomized> <Logo>C:WindowsSystem32OOBEInfosurface.bmp</Logo> <Manufacturer>Microsoft Corporation</Manufacturer> <SupportURL>http://www.microsoft.com/surface/support</SupportURL> <SupportPhone> U.S./Canada: 1-800-Microsoft (642-7676); Mexico: 01 800 123 3353 </SupportPhone> </OEMInformation> <OOBE> <HideEULAPage>true</HideEULAPage> <HideLocalAccountScreen>false</HideLocalAccountScreen> <HideOnlineAccountScreens>false</HideOnlineAccountScreens> <HideWirelessSetupInOOBE>true</HideWirelessSetupInOOBE> <NetworkLocation>Work</NetworkLocation> <ProtectYourPC>1</ProtectYourPC> <HideOEMRegistrationScreen>true</HideOEMRegistrationScreen> </OOBE> <StartTiles> <WideTiles> <WideTile1> DEPLOYING WINDOWS RT 8.1 42
  • 45. <AppId>Microsoft.FreshPaint_8wekyb3d8bbwe!Microsoft.FreshPaint</AppId> </WideTile1> </WideTiles> <SquareTiles> <SquareTile1> <AppId> Microsoft.Office.OneNote_8wekyb3d8bbwe!microsoft.onenoteim </AppId> </SquareTile1> <SquareTile2> <AppId>Microsoft.SkypeWiFi_kzf8qxf38zg5c!App</AppId> </SquareTile2> </SquareTiles> </StartTiles> <UserAccounts> <LocalAccounts> <LocalAccount wcm:action=”add”> <Password> <Value>Passw0rd</Value> <PlainText>true</PlainText> </Password> <Description></Description> <DisplayName>SchoolAdmin</DisplayName> <Name>SchoolAdmin</Name> <Group>Administrators</Group> </LocalAccount> </LocalAccounts> </UserAccounts> <RegisteredOrganization>Contoso</RegisteredOrganization> <RegisteredOwner>Contoso</RegisteredOwner> <TimeZone>Pacific Standard Time</TimeZone> </component> <component name=”Microsoft-Windows-International-Core” processorArchitecture=”arm” publicKeyToken=”31bf3856ad364e35” language=”neutral” versionScope=”nonSxS” xmlns:wcm=”http://schemas.microsoft.com/WMIConfig/2002/State” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”> <InputLocale>0409:00000409</InputLocale> <SystemLocale>en-US</SystemLocale> <UILanguage>en-US</UILanguage> <UserLocale>en-US</UserLocale> </component> </settings> </unattend> DEPLOYING WINDOWS RT 8.1 43
  • 46. Network filtering recommendations A common challenge in schools is providing student access to the Internet from Windows RT devices. Schools use network filters that work seamlessly with domain-joined PCs but not workgroup devices, like Windows RT devices. There are three ways to get these devices through firewalls: • User authentication  After students sign in to their Windows RT device by using their local or Microsoft accounts, they can authenticate with the firewall by using their domain accounts. This method has the added benefit that tracking behavior to individuals is easier than other methods (e.g., bullying investigations). • MAC security filtering  A common solution is to enable MAC address security filtering on the firewall, then adding each Windows RT device’s MAC address to it. Listing 3 records each device’s name and MAC address in the Logs folder to provide the data for this solution. • Certificate-based authentication  Schools can install certificates on Windows RT devices and use them to authenticate with the firewall. Deploying certificates to the devices and configuring certificate-based authentication can be challenging to automate, but Windows Intune plus System Center 2012 R2 Configuration Manager provides this functionality. DEPLOYING WINDOWS RT 8.1 44
  • 47. Local Group Policy settings Table 2 describes Group Policy settings that schools might evaluate when planning Windows RT deployment. Many of these policies might leave the device in a state where it is difficult to manage or support. Schools have a tendency to over-manage Windows RT devices by using local Group Policy when they would be better off allowing the standard user account to do its job. For example, instead of locking all users out of the Control Panel, simply rely on standard user accounts not being able to change system settings that adversely affect the device. Likewise, standard users cannot save or change files in system folders. Table 2  Local Group Policy settings for evaluation Location Name Computer ConfigurationWindows Settings Security SettingsAccount Policies • Password Policy Computer ConfigurationAdministrative TemplatesWindows ComponentsApp Package Deployment • Allow all trusted apps to install Computer ConfigurationAdministrative TemplatesEdge UI • Disable help tips Computer ConfigurationAdministrative TemplatesSync your settings • Do not sync User ConfigurationScripts • Logon • Logoff User ConfigurationAdministrative Templates Control Panel • Hide specified Control Panel items • Prohibit access to Control Panel and PC settings • Show only specified Control Panel items DEPLOYING WINDOWS RT 8.1 45
  • 48. Location Name User ConfigurationAdministrative Templates Start Menu and Taskbar • Clear history of recently opened documents on exit • Clear history of tile notifications on exit • Go to the desktop instead of Start when signing in • Lock the Taskbar • Start Screen Layout • Prevent users from customizing their Start screen • Do not keep history of recently opened documents • Prevent changes to Taskbar and Start menu settings • Prevent users from uninstalling applications from Start • Pin apps to Start when installed User ConfigurationAdministrative Templates System • Prevent access to the command prompt • Prevent access to registry editing tools • Don’t run specified Windows applications • Run only specified Windows applications User ConfigurationAdministrative Templates SystemLogon • Run these programs at user logon User ConfigurationAdministrative Templates Windows ComponentsApp runtime • Allow Microsoft accounts to be optional User ConfigurationAdministrative Templates Windows ComponentsCredential user interface • Do not display the password reveal button User ConfigurationAdministrative Templates Windows ComponentsFile Explorer • Hide the drop-down list of recent files • Hide the common dialog Places Bar • Items displayed in Places Bar User ConfigurationAdministrative Templates Windows ComponentsInternet Explorer • Do not allow users to enable or disable add-ons User ConfigurationAdministrative Templates Windows ComponentsInternet Explorer Internet Control PanelSecurity Page • Site to Zone Assignment List DEPLOYING WINDOWS RT 8.1 • User data persistence 46
  • 49. Location Name User ConfigurationAdministrative Templates Windows ComponentsInternet Explorer Internet Settings • Set how links are opened in Internet Explorer User ConfigurationAdministrative Templates Windows ComponentsRemote Desktop ServicesRemote Desktop Connection Client • Do not allow passwords to be saved User ConfigurationAdministrative TemplatesWindows ComponentsRemote Desktop ServicesRemoteApp and Desktop Connections • Specific default connection URL User ConfigurationAdministrative Templates Windows ComponentsStore • Turn off the offer to update to the latest version of Windows • Open Internet Explorer tiles on the desktop • Turn off the Store application User ConfigurationAdministrative Templates Windows ComponentsWindows Mail DEPLOYING WINDOWS RT 8.1 • Turn off Windows Mail application 47

×