Windows RT 8.1 Deployment Process

Applies To: Windows 8.1

For a Windows RT 8.1 deployment in education you have two primary choices for deployment: shared-device or a one-to-one scenario.

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

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 (in other words, 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 OneDrive.

• 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 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 (for example, 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 Local Group Policy Settings section 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 Network Filtering Recommendations section 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 Local Group Policy Settings section.)

• 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 OneDrive, and their settings do not synchronize. Students with access to Office 365 can use OneDrive 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.

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. Create the Configuration Store 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 is described in Preparing Shared Devices for Delivery.

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.

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. Create the Configuration Store 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 Preparing Personal Devices for Delivery 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.

4. Deliver the device to the student. When the student turns on the device, the OOBE starts.

Preparing Personal Devices for Delivery describes this process in step-by-step detail, including how to start the device in Audit mode, plus sample script listings.

See also

• Deploy Windows RT 8.1: A Guide for Education