Deploying Windows RT 8.1 - A Guide for Education

7/26/2019 Deploying Windows RT 8.1 - A Guide for Education

1/49

January 2014


2/49

Table of

contents

2 Choosing a student account

4 Deployment process overview

5 Shared-device scenarios

7 One-to-one scenarios

9 Crea he courao ore

10 Apps

11 Files

11 Logs

13 Policies

16 Proles

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/49

1DEPLOYING WINDOWS RT 8.1

Deploying Windows RT 8.1A guide for education

This guide prescribes processes and provides a sample script

framework that is specic 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 areultraportable, 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, WindowsRT8.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 conguration

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 conguration.

NOTE The listings in this guide are formatted for print media. Do not copy and paste them from thisguide. Instead, download the sample scripts from the TechNet Script Center at http://gallery.technet.

microsoft.com/scriptcenter/Windows-RT-81-conguration-6b06b65a . Download edu_cong.zip and

extract its contents to a USB ash drive or another location. The contents include the template folderstructure and scripts.
http://aka.ms/windowsrt4enterprisehttp://aka.ms/windowsrt4enterprisehttp://gallery.technet.microsoft.com/scriptcenter/Windows-RT-81-configuration-6b06b65ahttp://gallery.technet.microsoft.com/scriptcenter/Windows-RT-81-configuration-6b06b65ahttp://gallery.technet.microsoft.com/scriptcenter/Windows-RT-81-configuration-6b06b65ahttp://gallery.technet.microsoft.com/scriptcenter/Windows-RT-81-configuration-6b06b65ahttp://aka.ms/windowsrt4enterprisehttp://aka.ms/windowsrt4enterprise


4/49


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 accountsin 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 accessedor 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 lters, le shares) by using their domain accounts.

Organizational accounts Also known as Windows Azure Active Directoryaccounts, these are

organization-oriented, Internet-based accounts that people use to access an organizations

subscription services, such as Microsoft Ofce 365 or Windows Intune. The school owns

organizational accounts, and its IT staff manage them. Schools can synchronize their on-

premises Active Directory infrastructure with Windows Azure AD.

NOTE Microsoft accounts in the United States comply with the Childrens Online PrivacyProtection 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 creditcard (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.
http://windows.microsoft.com/en-us/windows-8/microsoft-account-tutorialhttp://windows.microsoft.com/en-us/windows-8/microsoft-account-tutorialhttp://windows.microsoft.com/en-us/windows-live/family-safety-why-doeshttp://windows.microsoft.com/en-us/windows-live/family-safety-why-doeshttp://windows.microsoft.com/en-us/windows-live/family-safety-why-doeshttp://windows.microsoft.com/en-us/windows-live/family-safety-why-doeshttp://windows.microsoft.com/en-us/windows-8/microsoft-account-tutorialhttp://windows.microsoft.com/en-us/windows-8/microsoft-account-tutorial


5/49


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

Ofce 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 childrens accounts.

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 moreinformation about gaining

an exception to this policy,

consult your account

team.


6/49


Deployment process overview

This guide prescribes processes and provides sample Windows PowerShell scripts that are specic

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 1for a brief comparison):

Shared-device scenarios In shared-device scenarios, Microsoft recommends signing in to

the device as an administrator and conguring 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, conguring it, and then using the System Preparation Tool (Sysprep) to seal itbefore delivering it to the student. Students sign in to their devices using Microsoft accounts.

TABLE 1 Scenario comparison

SHAREDSCENARIO ONE-TO-ONESCENARIO

Recommendedaccount type

Local Windows account Microsoft account

Student accountprivilege level

Standard user accounts Administrator accounts

COPPA compliance UnnecessaryStudents under 13 years of age

must have parental consent

Privacyconsiderations

Must prevent students fromcaching their credentials andsaving les to the local device

Because students do not share theirdevices, their information is private aslong as they protect their credentials

Students can installapps from the

Windows StoreNo Yes

Acce le oSkyDrive

No Yes

Use the Mail appwh Ofce 365 or

an on-premisesmail server

No Yes


7/49


SHAREDSCENARIO ONE-TO-ONESCENARIO

Potential formisuse

Some; students do have some anonymitywhen using shared devices, but you canidentify a devices user if you requirestudents to use domain credentials

to sign in to the network rewall

Some; students do not have anonymity,but they do have full administrator

access to their devices to install apps,congure settings, and so on

Deploymentinteraction

Signicant interaction to completethe Out-of-Box Experience (OOBE)

but automated afterward

Light interaction that skips theOOBE 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 rst 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 congure 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 congure the device to sign in to the desktop automatically. (You can

use netplwiz.cpl to congure automatic sign-in, and the sample scripts in this guide congure

automatic sign-in during the conguration 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


8/49


use their organizational account to access Ofce 365 or their domain account to access network

resources.

Importantly, the local Windows account that you create on each device should be a standarduser 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 le 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 dene 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 les in system folders. In shared-device scenarios, students should be made to understand

that any le 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

lter by using their domain credentials. (See the section, Network ltering 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 Ofce 365 can use SkyDrive Pro to make their les available on each shared device

they use.

The deployment process for this scenario can require signicant 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.


9/49


Prior to beginning device conguration, prepare the conguration

store by customizing the scripts provided with this guide and stocking

the store with the required source les. The section, Creating the

conguration 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 congure 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 conguration script that the section Preparing shared

devices for delivery on page 26describes to congure 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 Ofce 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.

NOTE

Forcing students to use

local Windows accounts

with least-privileged

access is difcult but

not impossible in one-

to-one scenarios. Theprocess 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.


10/49


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 conguration, prepare the conguration

store by customizing the scripts provided with this guide and stocking

the store with the required source les. The section, Creating the

conguration 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 conguration script that the section Preparing personal

devices for delivery on page 33describes to congure the

device. After the script nishes conguring the device, it runs

Sysprep to prepare the device for delivery to the student and

shut it down.

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.

NOTE

By design, the local

administrator account

cannot run Windows Store

apps.


11/49


Creating the confguration store

The confguration storeis where you store the source les and scripts

that congure each device. Use the same conguration store for

both deployment scenarios. You can locate the conguration store

on a USB ash drive or a network share. (You can also keep a master

copy of the conguration store on a network share and copy it to

USB ash drives to expedite conguration for each installer.) This

guide assumes that the conguration store is on a USB ash drive

in D:\Store. By default, the scripts in this guide look for les in the

following subfolders:

Apps Windows Store apps tosideload on devices

Files Extra les to copy to

devices

Logs Target location in which to

log devices names, media access

control (MAC) addresses, and

serial numbers

Policies Local Group Policy

settings to copy to devices

Prole Wireless networkingproles to add to devices

Scripts Scripts required to

congure devices

Settings REG les to import into

devices registries

Tasks Scheduled tasks to import

on devices

Updates Update packages

(MSU les) to install on devices

If you store the conguration store on a network share, guest access

must be enabled on the conguration store. Otherwise, installers

must provide domain credentials when preparing devices. Enabling

guest access on the conguration store helps streamline the process.

Because Microsoft recommends guest access for the conguration

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. Alaptop or network-attached storage device is perfect for this purpose.

The following subsections tackle individual folders in the

conguration store separately, including the sample scripts that drive

each. The sections, Preparing shared devices for delivery on page

26and Preparing personal devices for delivery on page 33,

give end-to-end examples that tie everything together.

WARNING

The scripts and source

les contain passwords in

plain textfor 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

conguration store.

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.


12/49


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 appmeans 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.aspxin the Microsoft TechNet library.

You need the apps package les to sideload them. Package flesare les with the .appx le

extension, and you obtain them from the apps developers. Keep in mind that few developers

provide package les 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 les they provide to the Apps subfolder of the conguration store. The script in Listing

1provisions each app in the given path on the target device, meaning that those apps will beavailable for all users who sign in to the device.

NOTE Sideloading apps on Windows RT devices requires that you rst 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 conguration 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 conguration store.

$AppPackages | ForEach-Object {

Write-Output ...$_ Add-AppxProvisionedPackage -Online -PackagePath $_ -SkipLicense }

Pop-Location

Write-Output Finished installing app packages on the device.
http://technet.microsoft.com/en-us/windows/dn260720.aspxhttp://technet.microsoft.com/en-us/windows/dn260720.aspxhttp://technet.microsoft.com/en-us/windows/dn260720.aspxhttp://technet.microsoft.com/en-us/windows/dn260720.aspx


13/49


}

else {

Write-Output Skipping Windows Store apps because path was not found. }

}

Files

The script in Listing 2has a simple but useful role. It replicates the contents of the Files subfolder

in the conguration store to the target device. To prepare the Files subfolder in the conguration

store, create the le and folder structure you want to replicate on the target device. Imagine that

the Files subfolder of the conguration store is the root of the system drive on the target device.

For example, if you create a text le named helloworld.txtin Files\Users\Public\Desktop, the script

in Listing 2copies that le to the public desktop on each device it runs. The script retains le

attributes and overwrites system, read-only, and hidden les.

LISTING 2 Apply-LocalFiles.ps1

function Apply-LocalFiles {

# Copy les and folders from the conguration store.

param (


Path of the folder containing folders and les to copy)][string] $Path, [Parameter(Mandatory=$true, HelpMessage = `

Target path to which to copy the source folders and les)][string] $Target )

if ((Test-Path -Path $Path -PathType Container)) { Write-Output Applying les 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 les and folders to this device. }

else {

Write-Output Skipping local les because path was not found. }

}

Logs

Some schools need to collect the MAC address of each Windows RT device as they congure it. For

example, schools that have network lters might prefer to use MAC security ltering rather than

requiring students to provide their domain credentials to get through the rewall. Collecting the

name and MAC address of each device during installation helps simplify the conguration of MAC

security ltering.


14/49


The script in Listing 3logs the computer name, its MAC address, and its serial number in the Logs

subfolder of the conguration store. Because you might have multiple installers setting up devices,

this script creates a separate text le for each device to avoid multiuser conicts if you are storing

them in a network share. The le name is the MAC address appended to the computer name. The

text le 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 les in to a Microsoft Excel spreadsheet to aggregate them.

NOTE You can customize Listing 3to collect additional information about devices.

LISTING 3 Log-DeviceWithMac.ps1

Function Log-DeviceWithMac {

# Create a le containing the computer name, MAC address # of the rst Wi-Fi adapter, and the devices serial number.

param (


Path in which to log the computers name, MAC address, and serial number)] ` [string] $Path

)


Write-Output Logging the computer name and MAC address in the conguration store.

$FileName = $env:ComputerName + _ + ` $((Get-NetAdapter -Name Wi-FI).MacAddress ) + .txt $FullFilePath = Join-Path $Path $FileName

# Check if the le exists do not write a new le, otherwise write the le.

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 conguration store.

} else {

Write-Output Did not log the device because path was not found. }

}


15/49


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

conguration that you can apply to many devices. The procedure is

as follows:

1. On a reference device, congure local Group Policy.

2. Copy the local Group Policy from the reference device to the

conguration store.

3. Apply the local Group Policy from the conguration 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_

WinRTin the TechNet library), the script in Listing 4demonstrates

how to enable the Group Policy service by using Windows PowerShell.

If you congure 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 congure policies on a reference device, use the Local Group

Policy Editor. To access it, type gpedit.mscon the Start screen, andthen press Enter. You can congure security policy and Administrative

Templates for both the computer and users. Examine each policys

description to determine whether it supports Windows RT devices.

You can also lter 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

NOTE

See the section, Local

Group Policy settings on

page 45, for a list of

settings that you might

explore for your schools

devices. To learn more

about local Group Policy,

see http://www.microsoft.

com/grouppolicy.
http://www.microsoft.com/grouppolicyhttp://www.microsoft.com/grouppolicyhttp://www.microsoft.com/grouppolicyhttp://www.microsoft.com/grouppolicy


16/49


http://technet.microsoft.com/en-us/library/cc725970.aspxin 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 congured policies on the reference device, copy them from the reference device

to the conguration store. The script in Listing 5is an example. (If the conguration store is on a

network share, you must connect to the conguration store by using an account that can write to

it.) This script uses the command-line tool Secedit.exe to export the devices security conguration

to an INF le (see the article, Secedit, http://technet.microsoft.com/en-us/library/hh875548.aspx

in the TechNet library). It also uses the Export-StartLayoutWindows PowerShell cmdlet to export

the current Start screen layout to an XML le. The script stores both les in the local Group Policy

object (GPOi.e., %SystemRoot%\System32\GroupPolicy). Then, it copies the local GPO from the

reference device to the conguration store.

Listing 5 Gather-GroupPolicy.ps1

function Gather-GroupPolicy {

# Capture local Group Policy and save in the conguration store. #

# Important: Make sure that the path and le name of $StartLayoutFile # is the same as used in the Start Menu Layout Group Policy setting. # By default, these scripts create the le layout.xml in the path # C:\Windows\System32\GroupPolicy. For more information, see

# Deploying Windows RT 8.1 in education.

param (


Path to the folder in which to store the local Group Policy object)] `

[string] $Path

)

$PolicySource = C:\Windows\System32\GroupPolicy $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 15reverses the process. It copies the local GPO from the

conguration store to the target device, then it uses Secedit to import security policy from the
http://technet.microsoft.com/en-us/library/cc725970.aspxhttp://technet.microsoft.com/en-us/library/hh875548.aspxhttp://technet.microsoft.com/en-us/library/hh875548.aspxhttp://technet.microsoft.com/en-us/library/cc725970.aspx


17/49


local GPO (i.e., %SystemRoot%\System32\GroupPolicy). Finally, it congures and starts the Group

Policy service and runs Gpupdate.exe to refresh Group Policy on the device.

Notice that Listing 6does not import the Start screen layout. Instead, the layout le is stored withinthe local GPO, and you must dene the policy setting named Start Screen Layoutusing the path

to the layout le (i.e., %SystemRoot%\System32\GroupPolicy\layout.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.aspxin the TechNet

library.

Listing 6 Apply-GroupPolicy.ps1

function Apply-GroupPolicy {

# Apply local Group Policy settings from A conguration store # to the local computer, and start the Group Policy service.

param (


Path of the folder containing the local Group Policy object to copy)] `

[string] $Path

)

$Target = C:\Windows\System32\GroupPolicy $SecurityInfPath = Join-Path $Target security.inf $SecuritySdbPath = Join-Path $Target secedit.sdb


Write-Output Conguring 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 ...Conguring security policy on the device. secedit /congure /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 conguring Group Policy on the device. }

else {

Write-Output Skipping Group Policy because path was not found. }

}
http://technet.microsoft.com/en-us/library/dn467928.aspxhttp://technet.microsoft.com/en-us/library/dn467928.aspx


18/49


Proles

The Proles folder of the conguration store contains wireless networking proles. The process is

as follows:

1. On a reference device, connect to each wireless network.

2. Use the example script in Listing 7to create a wireless network prole for each connection in

the conguration store. The script creates one XML le for each prole.

3. Use the example script in Listing 8to add each wireless network prole in the Proles 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-WirelessProles.ps1

function Gather-WirelessProles {

# Export all wireless proles on the device to the given $Path.

param (


Path to the folder in which to store wireless proles)][string] $Path )

if (!(Test-Path $Path)) {

throw Unable to export wireless proles. $Path was not found. }

Write-Output Gathering wireless proles to $Path.

netsh.exe wlan export prole folder=$Path key=clear ` | Tee-Object -Variable Results | Out-Null


throw $Results

}

Write-Output Finished gathering wireless proles to $Path.}

LISTING 8 Apply-WirelessProles.ps1

function Apply-WirelessProles {

# Import each wireless prole found in the conguration store.

param (


Path of the folder containing wireless proles to add to the device)] ` [string] $Path,


Name of the interface with which to associate the wireless proles)] ` [string] $Interface


19/49


)



$Proles = Get-ChildItem -Filter *.xml

$ProlesCount = ($Proles | Measure-Object).Count Write-Output Importing ($ProlesCount) wireless proles from the conguration store.

$Proles | ForEach-Object { Write-Output ...$_

netsh.exe wlan add prole lename=$_ interface=$Interface ` | Tee-Object -Variable Results | Out-Null


throw $Results

}

}

Pop-Location Write-Output Finished importing wireless proles from the conguration store. }

else {

Write-Output Skipping wireless proles 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 les. After editing them so that they

contain only the settings you want to deploy, store them in the Settings subfolder of the

conguration 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).aspxin the

MSDN library before adding REG les to the conguration store. You must understand how

to create REG les that contain only the settings you want to deploy.

The script in Listing 9imports each REG le it nds in the conguration stores Settings folderinto the target devices registry. This is an easy way to congure system and user settings that you

cannot congure through local Group Policy.

LISTING 9 Apply-RegFiles.ps1

function Apply-RegFiles {

# Import each registry le found in the conguration store.
http://msdn.microsoft.com/en-us/library/windows/desktop/ms724182(v=vs.85).aspxhttp://msdn.microsoft.com/en-us/library/windows/desktop/ms724182(v=vs.85).aspx


20/49


param (


Path of the folder containing registry (REG) les to import on the device)]` [string] $Path

)



$RegFiles = Get-ChildItem -Filter *.reg

$RegFileCount = ($RegFiles | Measure-Object).Count Write-Output Importing ($RegFileCount) REG les from the conguration 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 les from the conguration 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 Conguration

Manager to manage Windows RT devices by using Mobile Device Management (MDM), but theycannot 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

conguration 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 schools 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 conguration store once each day, allowing you to update the local GPOs

beyond initial delivery. Listing 10and Listing 11 on page 19are examples. Schedule Listing 10,which is a batch script that runs the Windows PowerShell script in Listing 11, bypassing execution

policy.

LISTING 10 Update-DeviceCong.cmd

@echo off

rem Update-DeviceCong.cmd


21/49


rem

rem Start Update-DeviceCong.ps1, bypassing execution policy.

powershell.exe -ExecutionPolicy Bypass ^

%~dp0Update-DeviceCong.ps1 -PoliciesPath D:\Store\Policies

LISTING 11 Update-DeviceCong.ps1

# Update-DeviceCong.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 congure Windows RT devices in schools.

param (


Path to the folder containing the local Group Policy object to copy)] `

[string] $PoliciesPath)

$ErrorActionPreference = Stop

# GLOBAL VARIABLES ##############################################

$PolicyTarget = C:\Windows\System32\GroupPolicy # DO NOT CHANGE

# If you change the following folder and le names, you must also change them in# Apply-SharedCong.pst, Apply-PersonalCong.pst, and Update-DeviceCong.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-Nullsecedit /congure /db $SecuritySdbFile /cfg $SecurityInfFile | Out-Nullgpupdate /force | Out-Null

The process is as follows:

1. On a reference device, congure each task that you want to schedule. Check the actions,

triggers, and settings carefully.

Microsoft recommends that you congure 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 yourtasks to make sure they work as expected.

2. Export each task denition to an XML le in the Tasks subfolder of the conguration store. In

Task Scheduler, click the task you want to export; then, click Exportin the Actions pane.

3. On each target device, import the task denitions from the conguration store.


22/49


Listing 12imports each XML le it nds in the Tasks subfolder of the conguration 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 12creates 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 conguration store.

param (


Path of the folder containing task (XML) les to import into scheduled tasks)]` [string] $Path,


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

)



# 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


throw $Results

}

net localgroup Administrators $TaskUser /add ` | Tee-Object -Variable Results | Out-Null


throw $Results

}

# Add each task le 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 conguration 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 conguration store. }

else {

Write-Output Skipping tasks because path was not found. }


23/49


}

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 les). (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 le your account team provides in the Updates

folder in the conguration store. The script in Listing 13automatically installs each update package

that it nds 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 conguration store. Windows RT does # not support WSUS and an update catalog is not available. Contact your # account team about acquiring update packages (MSU les).

param (


Folder containing Microsoft update (MSU) les 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 conguration store.

$UpdatePackages | ForEach-Object { Write-Output ...$_ $cmd = wusa $_ /quiet /norestart Invoke-Expression $cmd

# Wait until the process nishes 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. }

}
http://support.microsoft.com/kb/934307http://support.microsoft.com/kb/934307


24/49


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 14shows 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 congure 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 congure automatic sign-in.

NOTE The script in Listing 14uses NET USERto add the shared user account, and it usesthe command-line option/expires:neverto 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 devices name.

param (


Password to use for the devices 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


throw $Results

}

Write-Output Conguring device to automatically sign in as $LocalUserName. Set-ItemProperty `

-Path HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ` -Name DefaultDomainName -Value $env:ComputerName | Out-Null


25/49


Set-ItemProperty -`

Path HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ` -Name DefaultUserName -Value $LocalUserName | Out-Null New-ItemProperty `

-Path HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ` -Name DefaultPassword -Value $Password | Out-Null Set-ItemProperty `

-Path HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ` -Name AutoAdminLogon -Value 1 | Out-Null

Write-Output Finished creating the local user account on the device.}


26/49


Building a complete solution

The sample scripts in Creating the conguration 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 conguration store and apply shared and

personal congurations.

You must stock most of the les in the conguration store manually. Copy APPX les to the

Apps subfolder, MSU les to the Updates subfolder, and so on. However, Listing 15and Listing 16

automatically copy local Group Policy settings and wireless networking proles from the reference

device to the conguration store. Listing 15is 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 congure.

Store both scripts in the Scripts subfolder of the conguration store so that you can access them

from any reference device. You specify the path to the conguration store in the last line of Listing

15.

Listing 15 Gather-DeviceCong.cmd

@echo off

rem Gather-DeviceCong.cmdrem

rem Start Gather-DeviceCong.ps1, bypassing execution policy.

powershell.exe -ExecutionPolicy Bypass ^ %~dp0Gather-DeviceCong.ps1 -StorePath D:\Store

Listing 16 Gather-DeviceCong.ps1

# Gather-DeviceCong.ps1#

# Gather conguration from reference device and save in the conguration store.# The conguration store can be on a USB ash 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 congure Windows RT devices in schools.

param (

[Parameter(Mandatory=$true, HelpMessage = ` Path to the folder containing the conguration store)][string] $StorePath)

$ErrorActionPreference = Stopif (!(Test-Path -Path $StorePath -PathType Container)) {

throw $StorePath was not found.}


# If you change the following folder and le names, you must also change them in


27/49


# Apply-SharedCong.pst, Apply-PersonalCong.pst, and Update-DeviceCong.pst.

$PoliciesPath = Join-Path $StorePath Policies

$ProlesPath = Join-Path $StorePath Proles

# FUNCTIONS #####################################################

function Gather-WirelessProles {

# Export all wireless proles on the device to the given $Path.

param (


Path to the folder in which to store wireless proles)][string] $Path )

if (!(Test-Path $Path)) {

throw Unable to export wireless proles. $Path was not found. }

Write-Output Gathering wireless proles to $Path.

netsh.exe wlan export prole folder=$Path key=clear ` | Tee-Object -Variable Results | Out-Null


throw $Results

}

Write-Output Finished gathering wireless proles to $Path.}

function Gather-GroupPolicy {

# Capture local Group Policy and save in the conguration store. #

# Important: Make sure that the path and le name of $StartLayoutFile

# is the same as used in the Start Menu Layout Group Policy setting. # By default, these scripts create the le layout.xml in the path # C:\Windows\System32\GroupPolicy. For more information, see

# Deploying Windows RT 8.1 in education.

param (


Path to the folder in which to store the local Group Policy object)] `

[string] $Path

)

$PolicySource = C:\Windows\System32\GroupPolicy $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


28/49


}

# MAIN ##########################################################

Write-Output Beginning to gather this devices conguration.Write-Output ------------------------------------------------------------------------Gather-GroupPolicy $PoliciesPath

Write-Output ------------------------------------------------------------------------

Gather-WirelessProles $ProlesPathWrite-Output ------------------------------------------------------------------------

Write-Output Finished gathering this devices conguration.

Preparing shared devices for delivery

Similar to the scripts in the previous section, Listing 17and Listing 18are complete examples that

rely on the examples you learned about in the section, Creating the conguration store on page

9. Listing 17runs the Windows PowerShell script in Listing 18while bypassing execution policy.

Listing 18is a working example that applies the contents of the previously prepared congurationstore to the target device.

Store both scripts in the Scripts subfolder of the conguration store so that you can access them

from any target device. You specify the path to the conguration 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 18while bypassing execution policy.

3. Perform any manual steps required to congure the device (e.g., installing Windows Store

apps).

4. Shut down the device, and deliver it to the classroom.

LISTING 17 Apply-SharedCong.cmd

@echo off

rem Apply-SharedCong.cmd

remrem Start Apply-SharedCong.ps1, bypassing execution policy.

powershell.exe -ExecutionPolicy Bypass ^ %~dp0Apply-SharedCong.ps1 -StorePath D:\Store

LISTING 18 Apply-SharedCong.ps1

# Apply-SharedCong.ps1#

# Apply settings from the conguration store to the local device.


29/49


# This script congures shared devices. See Apply-PersonalCong.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 congure Windows RT devices in schools.

param (


Path to the folder containing the conguration store)][string] $StorePath)




# The following variables dene subfolder names within# the conguration store. These scripts expect specic types# of les to appear in specic subfolders. If you change the

# following folder and le names, you must also change them in# Gather-DeviceCong.pst, Apply-PersonalCong.pst, and# Update-DeviceCong.pst.

$AppsPath = Join-Path $StorePath Apps

$FilesPath = Join-Path $StorePath Files

$LogsPath = Join-Path $StorePath Logs


$ProlesPath = Join-Path $StorePath Proles$SettingsPath = Join-Path $StorePath Settings

$TasksPath = Join-Path $StorePath Tasks

$UpdatesPath = Join-Path $StorePath Updates

# The following variables dene 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 = DevAdmin$TaskPassword = Passw0rd

# Additional variables:

$Interface = Wi-Fi # The name of the Wi-Fi interface on Surface devices

$UserPassword = Passw0rd # The password to use when creating the shared user account$FilesTarget = C: # The root of the le system for applying local les.

# FUNCTIONS #####################################################


# Install each Windows Store app from the conguration store.

# Make sure the Group Policy setting AllowAllTrustedApps is enabled # and a sideloading product key is installed on the device.

param (


Path of the folder containing Windows Store app (APPX) packages)] `

[string] $Path

)




30/49


$AppPackages = Get-ChildItem -Filter *.appx

$PackageCount = ($AppPackages | Measure-Object).Count

Write-Output Installing ($PackageCount) apps from the conguration store.



Pop-Location

Write-Output Finished installing app packages on the device. }

else {


}



param (





Write-Output Applying les and folders to this device. xcopy.exe $Path\*.* $Target\*.* /s /d /e /h /r /k /y ` | Tee-Object -Variable Results | Out-Null


throw $Results

} Write-Output Finished applying les and folders to this device. }

else {

Write-Output Skipping local les because path was not found. }

}



param (


Path in which to log the computers name, MAC address, and serial number)] `

[string] $Path )


Write-Output Logging the computer name and MAC address in the conguration store.




31/49






Write-Output `

Finished logging the computer name and MAC address in the conguration store. }

else {


}




Start-Service -Name gpsvc}



param (



[string] $Path

)





throw $Results

}

Write-Output ...Conguring security policy on the device. secedit /congure /db $SecuritySdbPath /cfg $SecurityInfPath | Out-Null



throw $Results

}


else {


}


32/49




param (


Path of the folder containing registry (REG) les to import on the device)] ` [string] $Path

)







throw $Results

}

}

Pop-Location


else {

Write-Output Skipping settings because path was not found. }

}



param (


Path of the folder containing task (XML) les to import into scheduled tasks)] ` [string] $Path,


Name of the account under which to run each imported scheduled task)] `


Password for the account under which to run each imported scheduled task)] `

[string] $TaskPassword

)






throw $Results

}



33/49



throw $Results

}






Pop-Location

Write-Output Finished importing scheduled tasks from the conguration store.

} else {


}



param (



)



$UpdatePackages = Get-ChildItem -Filter *.msu

$PackageCount = ($UpdatePackages | Measure-Object).Count Write-Output Installing ($PackageCount) updates from the conguration store.

$UpdatePackages | ForEach-Object { Write-Output ...$_ $cmd = wusa $_ /quiet /norestart Invoke-Expression $cmd

# Wait until the process nishes 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. }


34/49


}

function Create-SharedUser {

# Provision a shared local account based on the devices name.

param (


Password to use for the devices 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 Conguring device to automatically sign in as $LocalUserName. Set-ItemProperty `

-Path HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ` -Name DefaultDomainName -Value $env:ComputerName | Out-Null

Set-ItemProperty `

-Path HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ` -Name DefaultUserName -Value $LocalUserName | Out-Null New-ItemProperty `

-Path HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ` -Name DefaultPassword -Value $Password | Out-Null

Set-ItemProperty ` -Path HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ` -Name AutoAdminLogon -Value 1 | Out-Null

Write-Output Finished creating the local user account on the device.}

function Apply-WirelessProles {

# Import each wireless prole found in the conguration store.

param (


Path of the folder containing wireless proles to add to the device)] ` [string] $Path,


Name of the interface with which to associate the wireless proles)] ` [string] $Interface

)



$Proles = Get-ChildItem -Filter *.xml

$ProlesCount = ($Proles | Measure-Object).Count Write-Output Importing ($ProlesCount) wireless proles from the conguration store.


35/49


$Proles | ForEach-Object { Write-Output ...$_

netsh.exe wlan add prole lename=$_ interface=$Interface ` | Tee-Object -Variable Results | Out-Null


throw $Results

}

}

Pop-Location

Write-Output Finished importing wireless proles from the conguration store. }

else {

Write-Output Skipping wireless proles because path was not found. }

}

# MAIN

Write-Output Beginning to congure this device for shared use.Write-Output ------------------------------------------------------------------------Apply-WirelessProles $ProlesPath $InterfaceWrite-Output ------------------------------------------------------------------------

Apply-LocalFiles $FilesPath $FilesTarget

Write-Output ------------------------------------------------------------------------

Apply-RegFiles $SettingsPath

Write-Output ------------------------------------------------------------------------

Apply-GroupPolicy $PoliciesPath

Write-Output ------------------------------------------------------------------------

Import-ScheduledTasks $TasksPath $TaskUser $TaskPasswordWrite-Output ------------------------------------------------------------------------

Apply-UpdateFiles $UpdatesPathWrite-Output ------------------------------------------------------------------------

Create-SharedUser $UserPasswordWrite-Output ------------------------------------------------------------------------

Apply-AppxPackages $AppsPathWrite-Output ------------------------------------------------------------------------

Log-DeviceWithMac $LogsPath

Write-Output ------------------------------------------------------------------------

Write-Output Finished conguring this device for shared use.

Preparing personal devices for delivery

When preparing personal devices for delivery, you use the same conguration store you used

for shared devices. That includes copying the local GPO and wireless networking proles from a

reference device to the conguration store, adding APPX and MSU les, and so on.

After you have stocked the conguration store, preparing personal devices for delivery canbe easier and a bit quicker than preparing shared devices, mainly because you do not have to

complete the OOBE when conguring the device. Instead, you start devices in Audit mode. In

Audit mode, you can congure and customize devices prior to delivering them to students. After

the rst 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.aspxin the TechNet library.
http://technet.microsoft.com/en-us/library/hh824891.aspxhttp://technet.microsoft.com/en-us/library/hh824891.aspxhttp://technet.microsoft.com/en-us/library/hh824891.aspxhttp://technet.microsoft.com/en-us/library/hh824891.aspx


36/49


To prepare personal devices for delivery, complete the following steps:

1. Start the device, and wait for the OOBE to begin.

2. Tap the Accessibilityicon, 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 nish while restarts are pending, Listing 20nishes by copying Exit-

AuditMode.ps1 (Listing 21) and Unattend.xml (Listing 22) to the device and congures 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-PersonalCong.cmd

@echo off

rem Apply-PersonalCong.cmdrem

rem Start Apply-PersonalCong.ps1, bypassing execution policy.

powershell.exe -ExecutionPolicy Bypass ^ %~dp0Apply-PersonalCong.ps1 -StorePath D:\Store

LISTING 20 Apply-PersonalCong.ps1

# Apply-PersonalCong.ps1#

# Apply settings from the conguration store to the local device,# and prepare the device for delivery to the student by running Sysprep.# This script congures personal devices. See Apply-SharedCong.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 congure Windows RT devices in schools.

param (


Path to the folder containing the conguration store)][string] $StorePath)




$ScriptPath = Split-Path -Parent $MyInvocation.MyCommand.Path

# The following variables dene subfolder names within


37/49


# the conguration store. These scripts expect specic types# of les to appear in specic subfolders. If you change the# following folder and le names, you must also change them in# Gather-DeviceCong.pst, Apply-PersonalCong.pst, and

# Update-DeviceCong.pst.

$AppsPath = Join-Path $StorePath Apps

$FilesPath = Join-Path $StorePath Files

$LogsPath = Join-Path $StorePath Logs


$ProlesPath = Join-Path $StorePath Proles$SettingsPath = Join-Path $StorePath Settings

$TasksPath = Join-Path $StorePath Tasks

$UpdatesPath = Join-Path $StorePath Updates

# The following variables dene 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 = DevAdmin$TaskPassword = Passw0rd

# Additional variables:

$Interface = Wi-Fi # The name of the Wi-Fi interface on Surface devices

$FilesTarget = C: # The root of the le system for applying local les.

# FUNCTIONS #####################################################


# Install each Windows Store app from the conguration 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

)



$AppPackages = Get-ChildItem -Filter *.appx

$PackageCount = ($AppPackages | Measure-Object).Count Write-Output Installing ($PackageCount) apps from the conguration store.



Pop-Location

Write-Output Finished installing app packages on the device. }

else {


}


38/49




param (





Write-Output Applying les and folders to this device. xcopy.exe $Path\*.* $Target\*.* /s /d /e /h /r /k /y ` | Tee-Object -Variable Results | Out-Null


throw $Results

}

Write-Output Finished applying les and folders to this device. }

else { Write-Output Skipping local les because path was not found. }

}



param (


Path in which to log the computers 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 conguration store.







Write-Output ` Finished logging the computer name and MAC address in the conguration store. }

else {


}




39/49



Start-Service -Name gpsvc

}



param (



[string] $Path

)





throw $Results

}

# For personal congurations, 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 ...Conguring security policy on the device. # secedit /congure /db $SecuritySdbPath /cfg $SecurityInfPath | Out-Null



throw $Results

}


else {


}



param (


Path of the folder containing registry (REG) les to import on the device)] ` [string] $Path

)



40/49







throw $Results

}

}

Pop-Location


else {

Write-Output Skipping settings because path was not found.

}}



param (


Path of the folder containing task (XML) les to import into scheduled tasks)] ` [string] $Path,


Name of the account under which to run each imported scheduled task)] `


Password for the account under which to run each imported scheduled task)] `

[string] $TaskPassword )






throw $Results

}


if ($LASTEXITCODE -ne 0) { throw $Results

}






41/49



Pop-Location

Write-Output Finished importing scheduled tasks from the conguration store. }

else {


}



param ( [Parameter(Mandatory=$true, HelpMessage = `


)

if ((Test-Path

Documents

Deploying Windows RT 8.1 - A Guide for Education