User Oobe Create Elevated Object Server - popularfasr. Recently had my computer reset to Factory default setting because I was having problems connecting to certain programs and apps. Can't seem to get past 'User OOBE Create elevated object server' icon at bottom of screen when I attempt to set up a second account. Why can't the above 'User OOBE, etc', be avoided? Set maximum wait time for the network if a user has a roaming user profile or remote home directory Set roaming profile path for all users logging onto this computer Set the schedule for background upload of a roaming user profile's registry file while user is logged on.

Azure Image Builder uses a .json file to pass information into the Image Builder service. In this article we will go over the sections of the json file, so you can build your own. To see examples of full .json files, see the Azure Image Builder GitHub.

This is the basic template format:

Type and API version

The type is the resource type, which must be 'Microsoft.VirtualMachineImages/imageTemplates'. The apiVersion will change over time as the API changes, but should be '2020-02-14' for preview.

Location

The location is the region where the custom image will be created. For the Image Builder preview, the following regions are supported:

• East US
• East US 2
• West Central US
• West US
• West US 2
• South Central US
• North Europe
• West Europe
• South East Asia
• Australia Southeast
• Australia East
• UK South
• UK West

Data Residency

The Azure VM Image Builder service doesn't store/process customer data outside regions that have strict single region data residency requirements when a customer requests a build in that region. In the event of a service outage for regions that have data residency requirements, you will need to create templates in a different region and geography.

Zone Redundancy

Distribution supports zone redundancy, VHDs are distributed to a Zone Redundant Storage account by default and the Shared Image Gallery version will support a ZRS storage type if specified.

vmProfile

buildVM

By default Image Builder will use a 'Standard_D1_v2' build VM, this is built from the image you specify in the source. You can override this and may wish to do this for these reasons:

1. Performing customizations that require increased memory, CPU and handling large files (GBs).
2. Running Windows builds, you should use 'Standard_D2_v2' or equivalent VM size.
3. Require VM isolation.
4. Customize an Image that require specific hardware, e.g. for a GPU VM, you need a GPU VM size.
5. Require end to end encryption at rest of the build VM, you need to specify the support build VM size that don't use local temporary disks.

This is optional.

Proxy VM Size

The proxy VM is used to send commands between the Azure Image Builder Service and the build VM, this is only deployed when specifying an existing VNET, for more details review the networking options documentation.

This is optional.

osDiskSizeGB

By default, Image Builder will not change the size of the image, it will use the size from the source image. You can only increase the size of the OS Disk (Win and Linux), this is optional, and a value of 0 means leave the same size as the source image. You cannot reduce the OS Disk size to smaller than the size from the source image.

vnetConfig

If you do not specify any VNET properties, then Image Builder will create its own VNET, Public IP, and NSG. The Public IP is used for the service to communicate with the build VM, however if you do not want a Public IP or want Image Builder to have access to your existing VNET resources, such as configuration servers (DSC, Chef, Puppet, Ansible), file shares etc., then you can specify a VNET. For more information, review the networking documentation, this is optional.

Tags

These are key/value pairs you can specify for the image that's generated.

Depends on (optional)

This optional section can be used to ensure that dependencies are completed before proceeding.

For more information, see Define resource dependencies.

Identity

Required - For Image Builder to have permissions to read/write images, read in scripts from Azure Storage you must create an Azure User-Assigned Identity, that has permissions to the individual resources. For details on how Image Builder permissions work, and relevant steps, please review the documentation.

Image Builder support for a User-Assigned Identity:

• Supports a single identity only
• Does not support custom domain names

To learn more, see What is managed identities for Azure resources?.For more information on deploying this feature, see Configure managed identities for Azure resources on an Azure VM using Azure CLI.

Properties: source

The source section contains information about the source image that will be used by Image Builder. Image Builder currently only natively supports creating Hyper-V generation (Gen1) 1 images to the Azure Shared Image Gallery (SIG) or Managed Image. If you want to create Gen2 images, then you need to use a source Gen2 image, and distribute to VHD. After, you will then need to create a Managed Image from the VHD, and inject it into the SIG as a Gen2 image.

The API requires a 'SourceType' that defines the source for the image build, currently there are three types:

• PlatformImage - indicated the source image is a Marketplace image.
• ManagedImage - use this when starting from a regular managed image.
• SharedImageVersion - this is used when you are using an image version in a Shared Image Gallery as the source.

Note

When using existing Windows custom images, you can run the Sysprep command up to 3 times on a single Windows 7 or Windows Server 2008 R2 image, or 1001 times on a single Windows image for later versions; for more information, see the sysprep documentation.

PlatformImage source

Azure Image Builder supports Windows Server and client, and Linux Azure Marketplace images, see here for the full list.

The properties here are the same that are used to create VM's, using AZ CLI, run the below to get the properties:

You can use 'latest' in the version, the version is evaluated when the image build takes place, not when the template is submitted. If you use this functionality with the Shared Image Gallery destination, you can avoid resubmitting the template, and rerun the image build at intervals, so your images are recreated from the most recent images.

Support for Market Place Plan Information

You can also specify plan information, for example:

ManagedImage source

Sets the source image as an existing managed image of a generalized VHD or VM.

Note

User Oobe Create Elevated Object Server Fix

The source managed image must be of a supported OS and the image must same region as your Azure Image Builder template.

The imageId should be the ResourceId of the managed image. Use az image list to list available images.

SharedImageVersion source

Sets the source image an existing image version in a Shared Image Gallery.

Note

The source managed image must be of a supported OS and the image must same region as your Azure Image Builder template, if not, please replicate the image version to the Image Builder Template region.

The imageVersionId should be the ResourceId of the image version. Use az sig image-version list to list image versions.

Properties: buildTimeoutInMinutes

By default, the Image Builder will run for 240 minutes. After that, it will timeout and stop, whether or not the image build is complete. If the timeout is hit, you will see an error similar to this:

If you do not specify a buildTimeoutInMinutes value, or set it to 0, this will use the default value. You can increase or decrease the value, up to the maximum of 960mins (16hrs). For Windows, we do not recommend setting this below 60 minutes. If you find you are hitting the timeout, review the logs, to see if the customization step is waiting on something like user input.

If you find you need more time for customizations to complete, set this to what you think you need, with a little overhead. But, do not set it too high because you might have to wait for it to timeout before seeing an error.

Properties: customize

Image Builder supports multiple ‘customizers’. Customizers are functions that are used to customize your image, such as running scripts, or rebooting servers.

When using customize:

• You can use multiple customizers, but they must have a unique name.
• Customizers execute in the order specified in the template.
• If one customizer fails, then the whole customization component will fail and report back an error.
• It is strongly advised you test the script thoroughly before using it in a template. Debugging the script on your own VM will be easier.
• Do not put sensitive data in the scripts.
• The script locations need to be publicly accessible, unless you are using MSI.

The customize section is an array. Azure Image Builder will run through the customizers in sequential order. Any failure in any customizer will fail the build process.

Note

Inline commands can be viewed in the image template definition and by Microsoft Support when helping with a support case. If you have sensitive information, it should be moved into scripts in Azure Storage, where access requires authentication.

Shell customizer

The shell customizer supports running shell scripts. The shell scripts must be publicly accessible or you must have configured an MSI for Image Builder to access them.

OS Support: Linux

Customize properties:

• type – Shell
• name - name for tracking the customization
• scriptUri - URI to the location of the file
• inline - array of shell commands, separated by commas.
• sha256Checksum - Value of sha256 checksum of the file, you generate this locally, and then Image Builder will checksum and validate.
  • To generate the sha256Checksum, using a terminal on Mac/Linux run: sha256sum <fileName>

Note

Inline commands are stored as part of the image template definition, you can see these when you dump out the image definition, and these are also visible to Microsoft Support in the event of a support case for troubleshooting purposes. If you have sensitive commands or values, it is strongly recommended these are moved into scripts, and use a user identity to authenticate to Azure Storage.

Super user privileges

For commands to run with super user privileges, they must be prefixed with sudo, you can add these into scripts or use it inline commands, for example:

Example of a script using sudo that you can reference using scriptUri:

Windows restart customizer

The Restart customizer allows you to restart a Windows VM and wait for it come back online, this allows you to install software that requires a reboot.

OS Support: Windows

Customize properties:

• Type: WindowsRestart
• restartCommand - Command to execute the restart (optional). The default is 'shutdown /r /f /t 0 /c 'packer restart'.
• restartCheckCommand – Command to check if restart succeeded (optional).
• restartTimeout - Restart timeout specified as a string of magnitude and unit. For example, 5m (5 minutes) or 2h (2 hours). The default is: '5m'

Linux restart

There is no Linux Restart customizer, however, if you are installing drivers, or components that require a restart, you can install them and invoke a restart using the Shell customizer, there is a 20min SSH timeout to the build VM.

PowerShell customizer

The shell customizer supports running PowerShell scripts and inline command, the scripts must be publicly accessible for the IB to access them.

OS support: Windows and Linux

Customize properties:

• type – PowerShell.
• scriptUri - URI to the location of the PowerShell script file.
• inline – Inline commands to be run, separated by commas.
• validExitCodes – Optional, valid codes that can be returned from the script/inline command, this will avoid reported failure of the script/inline command.
• runElevated – Optional, boolean, support for running commands and scripts with elevated permissions.
• sha256Checksum - Value of sha256 checksum of the file, you generate this locally, and then Image Builder will checksum and validate.
  • To generate the sha256Checksum, using a PowerShell on Windows Get-Hash

File customizer

The File customizer lets Image Builder download a file from a GitHub repo or Azure storage. If you have an image build pipeline that relies on build artifacts, you can set the file customizer to download from the build share, and move the artifacts into the image.

OS support: Linux and Windows

File customizer properties:

• sourceUri - an accessible storage endpoint, this can be GitHub or Azure storage. You can only download one file, not an entire directory. If you need to download a directory, use a compressed file, then uncompress it using the Shell or PowerShell customizers.

Note

If the sourceUri is an Azure Storage Account, irrespective if the blob is marked public, you will to grant the Managed User Identity permissions to read access on the blob. Please see this example to set the storage permissions.

• destination – this is the full destination path and file name. Any referenced path and subdirectories must exist, use the Shell or PowerShell customizers to set these up beforehand. You can use the script customizers to create the path.

This is supported by Windows directories and Linux paths, but there are some differences:

• Linux OS’s – the only path Image builder can write to is /tmp.
• Windows – No path restriction, but the path must exist.

If there is an error trying to download the file, or put it in a specified directory, then customize step will fail, and this will be in the customization.log.

Note

The file customizer is only suitable for small file downloads, < 20MB. For larger file downloads, use a script or inline command, then use code to download files, such as, Linux wget or curl, Windows, Invoke-WebRequest.

Windows Update Customizer

This customizer is built on the community Windows Update Provisioner for Packer, which is an open source project maintained by the Packer community. Microsoft tests and validate the provisioner with the Image Builder service, and will support investigating issues with it, and work to resolve issues, however the open source project is not officially supported by Microsoft. For detailed documentation on and help with the Windows Update Provisioner, please see the project repository.

OS support: Windows

Customizer properties:

• type – WindowsUpdate.
• searchCriteria - Optional, defines which type of updates are installed (Recommended, Important etc.), BrowseOnly=0 and IsInstalled=0 (Recommended) is the default.
• filters – Optional, allows you to specify a filter to include or exclude updates.
• updateLimit – Optional, defines how many updates can be installed, default 1000.

Note

The Windows Update customizer can fail if there are any outstanding Windows restarts, or application installations still running, typically you may see this error in the customization.log, System.Runtime.InteropServices.COMException (0x80240016): Exception from HRESULT: 0x80240016. We strongly advise you consider adding in a Windows Restart, and/or allowing applications enough time to complete their installations using sleep or wait commands in the inline commands or scripts before running Windows Update.

Generalize

By default, Azure Image Builder will also run ‘deprovision’ code at the end of each image customization phase, to ‘generalize’ the image. Generalizing is a process where the image is set up so it can be reused to create multiple VMs. For Windows VMs, Azure Image Builder uses Sysprep. For Linux, Azure Image Builder runs ‘waagent -deprovision’.

The commands Image Builder users to generalize may not be suitable for every situation, so Azure Image Builder will allow you to customize this command, if needed.

If you are migrating existing customization, and you are using different Sysprep/waagent commands, you can use the Image Builder generic commands, and if the VM creation fails, use your own Sysprep or waagent commands.

If Azure Image Builder creates a Windows custom image successfully, and you create a VM from it, then find that the VM creation fails or does not complete successfully, you will need to review the Windows Server Sysprep documentation or raise a support request with the Windows Server Sysprep Customer Services Support team, who can troubleshoot and advise on the correct Sysprep usage.

Default Sysprep command

Default Linux deprovision command

Overriding the Commands

To override the commands, use the PowerShell or Shell script provisioners to create the command files with the exact file name, and put them in the correct directories:

• Windows: c:DeprovisioningScript.ps1
• Linux: /tmp/DeprovisioningScript.sh

Image Builder will read these commands, these are written out to the AIB logs, ‘customization.log’. See troubleshooting on how to collect logs.

Properties: distribute

Azure Image Builder supports three distribution targets:

• managedImage - managed image.
• sharedImage - Shared Image Gallery.
• VHD - VHD in a storage account.

You can distribute an image to both of the target types in the same configuration.

Note

The default AIB sysprep command does not include '/mode:vm', however this maybe required when create images that will have the HyperV role installed. If you need to add this command argument, you must override the sysprep command.

Because you can have more than one target to distribute to, Image Builder maintains a state for every distribution target that can be accessed by querying the runOutputName. The runOutputName is an object you can query post distribution for information about that distribution. For example, you can query the location of the VHD, or regions where the image version was replicated to, or SIG Image version created. This is a property of every distribution target. The runOutputName must be unique to each distribution target. Here is an example, this is querying a Shared Image Gallery distribution:

Output:

Distribute: managedImage

The image output will be a managed image resource.

Distribute properties:

• type – managedImage
• imageId – Resource ID of the destination image, expected format: /subscriptions/<subscriptionId>/resourceGroups/<destinationResourceGroupName>/providers/Microsoft.Compute/images/<imageName>
• location - location of the managed image.
• runOutputName – unique name for identifying the distribution.
• artifactTags - Optional user specified key value pair tags.

Note

The destination resource group must exist.If you want the image distributed to a different region, it will increase the deployment time .

Distribute: sharedImage

The Azure Shared Image Gallery is a new Image Management service that allows managing of image region replication, versioning and sharing custom images. Azure Image Builder supports distributing with this service, so you can distribute images to regions supported by Shared Image Galleries.

A Shared Image Gallery is made up of:

• Gallery - Container for multiple shared images. A gallery is deployed in one region.
• Image definitions - a conceptual grouping for images.
• Image versions - this is an image type used for deploying a VM or scale set. Image versions can be replicated to other regions where VMs need to be deployed.

Before you can distribute to the Image Gallery, you must create a gallery and an image definition, see Shared images.

Distribute properties for shared image galleries:

• type - sharedImage

• galleryImageId – ID of the shared image gallery, this can specified in two formats:

  • Automatic versioning - Image Builder will generate a monotonic version number for you, this is useful for when you want to keep rebuilding images from the same template: The format is: /subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.Compute/galleries/<sharedImageGalleryName>/images/<imageGalleryName>.
  • Explicit versioning - You can pass in the version number you want image builder to use. The format is:/subscriptions/<subscriptionID>/resourceGroups/<rgName>/providers/Microsoft.Compute/galleries/<sharedImageGalName>/images/<imageDefName>/versions/<version e.g. 1.1.1>

• runOutputName – unique name for identifying the distribution.

• artifactTags - Optional user specified key value pair tags.

• replicationRegions - Array of regions for replication. One of the regions must be the region where the Gallery is deployed. Adding regions will mean an increase of build time, as the build does not complete until the replication has completed.

• excludeFromLatest (optional) This allows you to mark the image version you create not be used as the latest version in the SIG definition, the default is 'false'.

• storageAccountType (optional) AIB supports specifying these types of storage for the image version that is to be created:

  • 'Standard_LRS'
  • 'Standard_ZRS'

Note

If the image template and referenced image definition are not in the same location, you will see additional time to create images. Image Builder currently does not have a location parameter for the image version resource, we take it from its parent image definition. For example, if an image definition is in westus and you want the image version replicated to eastus, a blob is copied to to westus, from this, an image version resource in westus is created, and then replicate to eastus. To avoid the additional replication time, ensure the image definition and image template are in the same location.

Distribute: VHD

You can output to a VHD. You can then copy the VHD, and use it to publish to Azure MarketPlace, or use with Azure Stack.

OS Support: Windows and Linux

Distribute VHD parameters:

• type - VHD.
• runOutputName – unique name for identifying the distribution.
• tags - Optional user specified key value pair tags.

Azure Image Builder does not allow the user to specify a storage account location, but you can query the status of the runOutputs to get the location.

Note

Once the VHD has been created, copy it to a different location, as soon as possible. The VHD is stored in a storage account in the temporary resource group created when the image template is submitted to the Azure Image Builder service. If you delete the image template, then you will lose the VHD.

Image Template Operations

Starting an Image Build

To start a build, you need to invoke 'Run' on the Image Template resource, examples of run commands:

Cancelling an Image Build

If you are running an image build that you believe is incorrect, waiting for user input, or you feel will never complete successfully, then you can cancel the build.

The build can be canceled any time. If the distribution phase has started you can still cancel, but you will need to clean up any images that may not be completed. The cancel command does not wait for cancel to complete, please monitor lastrunstatus.runstate for canceling progress, using these status commands.

Examples of cancel commands:

Next steps

There are sample .json files for different scenarios in the Azure Image Builder GitHub.

Applies to: Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Server 2019, Windows Server 2016, Windows Server (Semi-annual Channel), Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2

This topic describes how to use Windows Server to deploy Roaming User Profiles to Windows client computers. Roaming User Profiles redirects user profiles to a file share so that users receive the same operating system and application settings on multiple computers.

For a list of recent changes to this topic, see the Change history section of this topic.

Important

Due to the security changes made in MS16-072, we updated Step 4: Optionally create a GPO for Roaming User Profiles in this topic so that Windows can properly apply the Roaming User Profiles policy (and not revert to local policies on affected PCs).

Important

User customizations to Start is lost after an OS in-place upgrade in the following configuration:

• Users are configured for a roaming profile
• Users are allowed to make changes to Start

As a result, the Start menu is reset to the default of the new OS version after the OS in-place upgrade. For workarounds, see Appendix C: Working around reset Start menu layouts after upgrades.

Prerequisites

Hardware requirements

Roaming User Profiles requires an x64-based or x86-based computer; it isn't supported by Windows RT.

Software requirements

Que Es User Oobe Create Elevated Object Server

Roaming User Profiles has the following software requirements:

• If you are deploying Roaming User Profiles with Folder Redirection in an environment with existing local user profiles, deploy Folder Redirection before Roaming User Profiles to minimize the size of roaming profiles. After the existing user folders have been successfully redirected, you can deploy Roaming User Profiles.

• To administer Roaming User Profiles, you must be signed in as a member of the Domain Administrators security group, the Enterprise Administrators security group, or the Group Policy Creator Owners security group.

• Client computers must run Windows 10, Windows 8.1, Windows 8, Windows 7, Windows Vista, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008.

• Client computers must be joined to the Active Directory Domain Services (AD DS) that you are managing.

• A computer must be available with Group Policy Management and Active Directory Administration Center installed.

• A file server must be available to host roaming user profiles.

  • If the file share uses DFS Namespaces, the DFS folders (links) must have a single target to prevent users from making conflicting edits on different servers.
  • If the file share uses DFS Replication to replicate the contents with another server, users must be able to access only the source server to prevent users from making conflicting edits on different servers.
  • If the file share is clustered, disable continuous availability on the file share to avoid performance issues.

• To use primary computer support in Roaming User Profiles, there are additional client computer and Active Directory schema requirements. For more information, see Deploy Primary Computers for Folder Redirection and Roaming User Profiles.

• The layout of a user's Start menu won't roam on Windows 10, Windows Server 2019, or Windows Server 2016 if they're using more than one PC, Remote Desktop Session Host, or Virtualized Desktop Infrastructure (VDI) server. As a workaround, you can specify a Start layout as described in this topic. Or you can make use of user profile disks, which properly roam Start menu settings when used with Remote Desktop Session Host servers or VDI servers. For more info, see Easier User Data Management with User Profile Disks in Windows Server 2012.

Considerations when using Roaming User Profiles on multiple versions of Windows

If you decide to use Roaming User Profiles across multiple versions of Windows, we recommend taking the following actions:

• Configure Windows to maintain separate profile versions for each operating system version. This helps prevent undesirable and unpredictable issues such as profile corruption.
• Use Folder Redirection to store user files such as documents and pictures outside of user profiles. This enables the same files to be available to users across operating system versions. It also keeps profiles small and sign-ins quick.
• Allocate sufficient storage for Roaming User Profiles. If you support two operating system versions, profiles will double in number (and thus total space consumed) because a separate profile is maintained for each operating system version.
• Don't use Roaming User Profiles across computers running Windows Vista/Windows Server 2008 and Windows 7/Windows Server 2008 R2. Roaming between these operating system versions isn't supported due to incompatibilities in their profile versions.
• Inform your users that changes made on one operating system version won't roam to another operating system version.
• When moving your environment to a version of Windows that uses a different profile version (such as from Windows 10 to Windows 10, version 1607—see Appendix B: Profile version reference information for a list), users receive a new, empty roaming user profile. You can minimize the impact of getting a new profile by using Folder Redirection to redirect common folders. There isn't a supported method of migrating roaming user profiles from one profile version to another.

Step 1: Enable the use of separate profile versions

If you are deploying Roaming User Profiles on computers running Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012, we recommend making a couple of changes to your Windows environment prior to deploying. These changes help ensure that future operating system upgrades go smoothly, and facilitate the ability to simultaneously run multiple versions of Windows with Roaming User Profiles.

To make these changes, use the following procedure.

1. Download and install the appropriate software update on all computers on which you're going to use roaming, mandatory, super-mandatory, or domain default profiles:

   • Windows 8.1, or Windows Server 2012 R2: install the software update described in article 2887595 in the Microsoft Knowledge Base (when released).
   • Windows 8 or Windows Server 2012: install the software update described in article 2887239 in the Microsoft Knowledge Base.

2. On all computers running Windows 8.1, Windows 8, Windows Server 2012 R2, or Windows Server 2012 on which you will use Roaming User Profiles, use Registry Editor or Group Policy to create the following registry key DWORD Value and set it to 1. For information about creating registry keys by using Group Policy, see Configure a Registry Item.

   Warning

   Incorrectly editing the registry may severely damage your system. Before making changes to the registry, you should back up any valued data on the computer.

3. Restart the computers.

Step 2: Create a Roaming User Profiles security group

If your environment is not already set up with Roaming User Profiles, the first step is to create a security group that contains all users and/or computers to which you want to apply Roaming User Profiles policy settings.

• Administrators of general-purpose roaming user profiles deployments typically create a security group for users.
• Administrators of Remote Desktop Services or virtualized desktop deployments typically use a security group for users and the shared computers.

Here's how to create a security group for Roaming User Profiles:

Microsoft Oobe Process

1. Open Server Manager on a computer with Active Directory Administration Center installed.

2. On the Tools menu, select Active Directory Administration Center. Active Directory Administration Center appears.

3. Right-click the appropriate domain or OU, select New, and then select Group.

4. In the Create Group window, in the Group section, specify the following settings:

   • In Group name, type the name of the security group, for example: Roaming User Profiles Users and Computers.
   • In Group scope, select Security, and then select Global.

5. In the Members section, select Add. The Select Users, Contacts, Computers, Service Accounts or Groups dialog box appears.

6. If you want to include computer accounts in the security group, select Object Types, select the Computers check box and then select OK.

7. Type the names of the users, groups, and/or computers to which you want to deploy Roaming User Profiles, select OK, and then select OK again.

Step 3: Create a file share for roaming user profiles

If you do not already have a separate file share for roaming user profiles (independent from any shares for redirected folders to prevent inadvertent caching of the roaming profile folder), use the following procedure to create a file share on a server running Windows Server.

Note

Some functionality might differ or be unavailable depending on the version of Windows Server you're using.

Here's how to create a file share on Windows Server:

1. In the Server Manager navigation pane, select File and Storage Services, and then select Shares to display the Shares page.

2. In the Shares tile, select Tasks, and then select New Share. The New Share Wizard appears.

3. On the Select Profile page, select SMB Share – Quick. If you have File Server Resource Manager installed and are using folder management properties, instead select SMB Share - Advanced.

4. On the Share Location page, select the server and volume on which you want to create the share.

5. On the Share Name page, type a name for the share (for example, User Profiles$) in the Share name box.

   Tip

   When creating the share, hide the share by putting a $ after the share name. This hides the share from casual browsers.

6. On the Other Settings page, clear the Enable continuous availability checkbox, if present, and optionally select the Enable access-based enumeration and Encrypt data access checkboxes.

7. On the Permissions page, select Customize permissions…. The Advanced Security Settings dialog box appears.

8. Select Disable inheritance, and then select Convert inherited permissions into explicit permission on this object.

9. Set the permissions as described in Required permissions for the file share hosting roaming user profiles and shown in the following screen shot, removing permissions for unlisted groups and accounts, and adding special permissions to the Roaming User Profiles Users and Computers group that you created in Step 1.

   Figure 1 Setting the permissions for the roaming user profiles share

10. If you chose the SMB Share - Advanced profile, on the Management Properties page, select the User Files Folder Usage value.

11. If you chose the SMB Share - Advanced profile, on the Quota page, optionally select a quota to apply to users of the share.

12. On the Confirmation page, select Create.

Required permissions for the file share hosting roaming user profiles

Step 4: Optionally create a GPO for Roaming User Profiles

If you do not already have a GPO created for Roaming User Profiles settings, use the following procedure to create an empty GPO for use with Roaming User Profiles. This GPO allows you to configure Roaming User Profiles settings (such as primary computer support, which is discussed separately), and can also be used to enable Roaming User Profiles on computers, as is typically done when deploying in virtualized desktop environments or with Remote Desktop Services.

Here's how to create a GPO for Roaming User Profiles:

1. Open Server Manager on a computer with Group Policy Management installed.

2. From the Tools menu select Group Policy Management. Group Policy Management appears.

3. Right-click the domain or OU in which you want to setup Roaming User Profiles, then select Create a GPO in this domain, and Link it here.

4. In the New GPO dialog box, type a name for the GPO (for example, Roaming User Profile Settings), and then select OK.

5. Right-click the newly created GPO and then clear the Link Enabled checkbox. This prevents the GPO from being applied until you finish configuring it.

6. Select the GPO. In the Security Filtering section of the Scope tab, select Authenticated Users, and then select Remove to prevent the GPO from being applied to everyone.

7. In the Security Filtering section, select Add.

8. In the Select User, Computer, or Group dialog box, type the name of the security group you created in Step 1 (for example, Roaming User Profiles Users and Computers), and then select OK.

9. Select the Delegation tab, select Add, type Authenticated Users, select OK, and then select OK again to accept the default Read permissions.

   This step is necessary due to security changes made in MS16-072.

Important

Due to the security changes made in MS16-072A, you now must give the Authenticated Users group delegated Read permissions to the GPO - otherwise the GPO won't get applied to users, or if it's already applied, the GPO is removed, redirecting user profiles back to the local PC. For more info, see Deploying Group Policy Security Update MS16-072.

Step 5: Optionally set up Roaming User Profiles on user accounts

If you are deploying Roaming User Profiles to user accounts, use the following procedure to specify roaming user profiles for user accounts in Active Directory Domain Services. If you are deploying Roaming User Profiles to computers, as is typically done for Remote Desktop Services or virtualized desktop deployments, instead use the procedure documented in Step 6: Optionally set up Roaming User Profiles on computers.

Note

If you set up Roaming User Profiles on user accounts by using Active Directory and on computers by using Group Policy, the computer-based policy setting takes precedence.

Here's how to set up Roaming User Profiles on user accounts:

1. In Active Directory Administration Center, navigate to the Users container (or OU) in the appropriate domain.

2. Select all users to which you want to assign a roaming user profile, right-click the users and then select Properties.

3. In the Profile section, select the Profile path: checkbox and then enter the path to the file share where you want to store the user's roaming user profile, followed by %username% (which is automatically replaced with the user name the first time the user signs in). For example:

   fs1.corp.contoso.comUser Profiles$%username%

   To specify a mandatory roaming user profile, specify the path to the NTuser.man file that you created previously, for example, fs1.corp.contoso.comUser Profiles$default. For more information, see Create mandatory user profiles.

4. Select OK.

Note

By default, deployment of all Windows® Runtime-based (Windows Store) apps is allowed when using Roaming User Profiles. However, when using a special profile, apps are not deployed by default. Special profiles are user profiles where changes are discarded after the user signs out:
To remove restrictions on app deployment for special profiles, enable the Allow deployment operations in special profiles policy setting (located in Computer ConfigurationPoliciesAdministrative TemplatesWindows ComponentsApp Package Deployment). However, deployed apps in this scenario will leave some data stored on the computer, which could accumulate, for example, if there are hundreds of users of a single computer. To clean up apps, locate or develop a tool that uses the CleanupPackageForUserAsync API to clean up app packages for users who no longer have a profile on the computer.
For additional background information about Windows Store apps, see Manage Client Access to the Windows Store.

Step 6: Optionally set up Roaming User Profiles on computers

If you are deploying Roaming User Profiles to computers, as is typically done for Remote Desktop Services or virtualized desktop deployments, use the following procedure. If you are deploying Roaming User Profiles to user accounts, instead use the procedure described in Step 5: Optionally set up Roaming User Profiles on user accounts.

You can use Group Policy to apply Roaming User Profiles to computers running Windows 8.1, Windows 8, Windows 7, Windows Vista, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2, or Windows Server 2008.

Note

If you set up Roaming User Profiles on computers by using Group Policy and on user accounts by using Active Directory, the computer-based policy setting takes precedence.

Here's how to set up Roaming User Profiles on computers:

1. Open Server Manager on a computer with Group Policy Management installed.

2. From the Tools menu, select Group Policy Management. Group Policy Management will appear.

3. In Group Policy Management, right-click the GPO you created in Step 3 (for example, Roaming User Profiles Settings), and then select Edit.

4. In the Group Policy Management Editor window, navigate to Computer Configuration, then Policies, then Administrative Templates, then System, and then User Profiles.

5. Right-click Set roaming profile path for all users logging onto this computer and then select Edit.

   Tip

   A user's home folder, if configured, is the default folder used by some programs such as Windows PowerShell. You can configure an alternative local or network location on a per-user basis by using the Home folder section of the user account properties in AD DS. To configure the home folder location for all users of a computer running Windows 8.1, Windows 8, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, or Windows Server 2012 in a virtual desktop environment, enable the Set user home folder policy setting, and then specify the file share and drive letter to map (or specify a local folder). Do not use environment variables or ellipses. The user's alias is appended to the end of the path specified during user sign on.

6. In the Properties dialog box, select Enabled

7. In the Users logging onto this computer should use this roaming profile path box, enter the path to the file share where you want to store the user's roaming user profile, followed by %username% (which is automatically replaced with the user name the first time the user signs in). For example:

   fs1.corp.contoso.comUser Profiles$%username%

   To specify a mandatory roaming user profile, which is a preconfigured profile to which users cannot make permanent changes (changes are reset when the user signs out), specify the path to the NTuser.man file that you created previously, for example, fs1.corp.contoso.comUser Profiles$default. For more information, see Creating a Mandatory User Profile.

8. Select OK.

Step 7: Optionally specify a Start layout for Windows 10 PCs

You can use Group Policy to apply a specific Start menu layout so that users see the same Start layout on all PCs. If users sign in to more than one PC and you want them to have a consistent Start layout across PCs, make sure that the GPO applies to all of their PCs.

To specify a Start layout, do the following:

1. Update your Windows 10 PCs to Windows 10 version 1607 (also known as the Anniversary Update) or newer, and install the March 14th, 2017 cumulative update (KB4013429) or newer.
2. Create a full or partial Start menu layout XML file. To do so, see Customize and export Start layout.
   • If you specify a full Start layout, a user can't customize any part of the Start menu. If you specify a partial Start layout, users can customize everything but the locked groups of tiles you specify. However, with a partial Start layout, user customizations to the Start menu won't roam to other PCs.
3. Use Group Policy to apply the customized Start layout to the GPO you created for Roaming User Profiles. To do so, see Use Group Policy to apply a customized Start layout in a domain.
4. Use Group Policy to set the following registry value on your Windows 10 PCs. To do so, see Configure a Registry Item.

5. (Optional) Enable first-time logon optimizations to make signing in faster for users. To do so, see Apply policies to improve sign-in time.
6. (Optional) Further decrease sign-in times by removing unnecessary apps from the Windows 10 base image you use to deploy client PCs. Windows Server 2019 and Windows Server 2016 don't have any pre-provisioned apps, so you can skip this step on server images.

   • To remove apps, use the Remove-AppxProvisionedPackage cmdlet in Windows PowerShell to uninstall the following applications. If your PCs are already deployed you can script the removal of these apps using the Remove-AppxPackage.

     • Microsoft.windowscommunicationsapps_8wekyb3d8bbwe
     • Microsoft.BingWeather_8wekyb3d8bbwe
     • Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
     • Microsoft.Getstarted_8wekyb3d8bbwe
     • Microsoft.Windows.Photos_8wekyb3d8bbwe
     • Microsoft.WindowsCamera_8wekyb3d8bbwe
     • Microsoft.WindowsFeedbackHub_8wekyb3d8bbwe
     • Microsoft.WindowsStore_8wekyb3d8bbwe
     • Microsoft.XboxApp_8wekyb3d8bbwe
     • Microsoft.XboxIdentityProvider_8wekyb3d8bbwe
     • Microsoft.ZuneMusic_8wekyb3d8bbwe

Note

Uninstalling these apps decreases sign-in times, but you can leave them installed if your deployment needs any of them.

User Oobe To Create Elevated Object Server

Step 8: Enable the Roaming User Profiles GPO

If you set up Roaming User Profiles on computers by using Group Policy, or if you customized other Roaming User Profiles settings by using Group Policy, the next step is to enable the GPO, permitting it to be applied to affected users.

Tip

If you plan to implement primary computer support, do so now, before you enable the GPO. This prevents user data from being copied to non-primary computers before primary computer support is enabled. For the specific policy settings, see Deploy Primary Computers for Folder Redirection and Roaming User Profiles.

Here's how to enable the Roaming User Profile GPO:

What Is Oobe Create Elevated Object Server

1. Open Group Policy Management.
2. Right-click the GPO that you created and then select Link Enabled. A checkbox appears next to the menu item.

Step 9: Test Roaming User Profiles

To test Roaming User Profiles, sign in to a computer with a user account configured for Roaming User Profiles, or sign in to a computer configured for Roaming User Profiles. Then confirm that the profile is redirected.

Here's how to test Roaming User Profiles:

1. Sign in to a primary computer (if you enabled primary computer support) with a user account for which you have enabled Roaming User Profiles enabled. If you enabled Roaming User Profiles on specific computers, sign in to one of these computers.

2. If the user has previously signed in to the computer, open an elevated command prompt, and then type the following command to ensure that the latest Group Policy settings are applied to the client computer:

3. To confirm that the user profile is roaming, open Control Panel, select System and Security, select System, select Advanced System Settings, select Settings in the User Profiles section and then look for Roaming in the Type column.

Appendix A: Checklist for deploying Roaming User Profiles

Appendix B: Profile version reference information

Each profile has a profile version that corresponds roughly to the version of Windows on which the profile is used. For example, Windows 10, version 1703 and version 1607 both use the .V6 profile version. Microsoft creates a new profile version only when necessary to maintain compatibility, which is why not every version of Windows includes a new profile version.

The following table lists the location of Roaming User Profiles on various versions of Windows.

Appendix C: Working around reset Start menu layouts after upgrades

Here are some ways to work around Start menu layouts getting reset after an in-place upgrade:

• If only one user ever uses the device and the IT Admin uses a managed OS deployment strategy such as Configuration Manager they can do the following:

  1. Export the Start menu layout with Export-Startlayout before the upgrade

  2. Import the Start menu layout with Import-StartLayout after OOBE but before the user signs in

     Note

     Importing a StartLayout modifies the Default User profile. All user profiles created after the import has occurred will get the imported Start-Layout.

• IT Admins can opt to manage Start's Layout with Group Policy. Using Group Policy provides a centralized management solution to apply a standardized Start Layout to users. There are 2 modes to modes to using Group Policy for Start management. Full Lockdown and Partial Lockdown. The full lockdown scenario prevents the user from making any changes to Start's layout. The partial lockdown scenario allows user to make changes to a specific area of Start. For more info, see Customize and export Start layout.

  Note

  User made changes in the partial lockdown scenario will still be lost during upgrade.

• Let the Start layout reset occur and allow end users to reconfigure Start. A notification email or other notification can be sent to end users to expect their Start layouts to be reset after the OS upgrade to minimized impact.

Change history

The following table summarizes some of the most important changes to this topic.

More information