Thursday, 2 October 2014

Windows 8.1 and Environment Manager Best Practices

It seems organisations are slowly but surely starting to adopt Windows 8.1 into their corporate networks because I've had a number of emails hit my inbox over the past few weeks asking for best practice information for the operating system.

In line with these requests read this article for a few items that I configure on every single Windows 8.x Environment Manager Configuration that I build:


1. Separate the Taskbar and Start Menu from the Windows 7 start menu

The taskbar is a bit of a complex beast consisting of both registry and folder items that need to co-exist in order to avoid having blank white icons appearing on the taskbar. We've known this for some time now however with the release of Windows 8.x the "Windows Explorer" icon was renamed to "File Explorer" so if you try and manage both of these items in a single Windows Personalization Group users are likely to get an error message when they attempt to launch Explorer on Windows 8.x.

2. Windows Start Screen

The start screen is fairly similar to the taskbar... a few files and a couple of registry keys. The complexity here is that as part of the logon process anything restored from Personalization Server is overwritten by the default Start Screen. The trick here is to use the Environment Manager processing order to your advantage.

Pre-Session trigger runs nice and early so use this trigger to set your Personalization Server using the AppSense provided GPO.

Personalization will then restore the appsFolder.itemdata-ms files and registry keys that store the actual start screen.

Next the Pre-Desktop trigger will run and we can use this to set the files above to read only effectively preventing Windows from overwriting these.

The last thing that needs to be done is removing the read only flag once logon is complete to allow users to pin new items to the start screen. Simply add the file attribute actions to the process started for an application that runs after logon. Anything in the startup folder, run registry, etc will do as the trigger.

3. Logon Video

The first time a user logs on to Windows 8.x an intro video plays. There are several ways to skin this cat but I prefer to simply implement the standard Microsoft Group Policy object preventing this from running at user logon. The GPO can be found here:

MACHINE\System\Logon\Show First Sign-in Animation

4. Wait for Network at Startup

Users with local profiles AND have fast logon enabled need to have this group policy enabled otherwise logon actions may not run and you could end up with a potentially un-locked / un-secure desktop. The GPO can be found here:

MACHINE\System\Logon\Always wait for the network at computer startup and logon

5. Require use of Fast Startup

As described above fast startup has been seen to cause issues in environments where users have local profiles and make use of AppSense Environment Manager. The GPO mentioned in point 4 will help mitigate this issue however you may also want to implement the GPO below to prevent fast startup from running. The GPO can be found here:

MACHINE\System\Shutdown\Require use of fast startup

6. v3 and v4 Profiles

By default Windows 8.0 and Windows 8.1 will default to using v2 profiles. This could be a problem if you wanted to house a number of mandatory profiles on a single share... for example:

\\SERVER\SHARE\Mandatory - Supporting Windows XP / Windows Server 2003 R2
\\SERVER\SHARE\Mandatory - Supporting Windows 7/ Windows Server 2008 R2
\\SERVER\SHARE\Mandatory - Supporting Windows 8 / Windows Server 2012
\\SERVER\SHARE\Mandatory - Supporting Windows 8.1 / Windows Server 2012 R2

The solution here is to implement a Microsoft hotfix described in the article 2887239 (https://support2.microsoft.com/kb/2887239) on the machines as well as the following registry key:

Registry Key: HKEY_LOCAL_MACHINE\System\CurrentControlset\Services\ProfSvc\Parameters
Value: UseProfilePathExtensionVersion
Value Type: DWORD
Value Data: 1
What this will do is cause each of the versions to use their own profile version as follows:

Windows XP / Windows Server 2003 R2 - Profile Version 1 (..\Mandatory)
Windows 7/ Windows Server 2008 R2 - Profile Version 2 (..\Mandatory.v2)
Windows 8 / Windows Server 2012 - Profile Version 3 (..\Mandatory.v3)
Windows 8.1 / Windows Server 2012 R2 - Profile Version 4 (..\Mandatory.v4)

Note: The hotfix is required on Windows 8.0 and Windows Server 2012 only.
Note: The registry key is required on Windows 8.0, Windows 8.1, Windows Server 2012 and Windows Server 2012 R2.

Some testing this morning has shown that Windows 10 will use profile version 5 and does not need the hotfix or registry key applied in order to implement this behaviour.

Any other questions let me know.

@UVarchitect