Group Policy Central

Remote Desktop Virtualisation is a feature of Windows that allows your users to run windows running remotely from server hardware. This is almost an identical concept with how Terminal Services (a.k.a. Remote Desktop Services, a.k.a. Remote Desktop Session Host) works where the users is sending keyboard and mouse messaged to the server and then receives the screen updates back. It is so similar in fact that both solution use the Remote Desktop Client and they also share the same Windows Server Remote Desktop Connection Broker role for users to connect to the computer they require.

The key difference is that the computer that the user connects to is a completely separate virtual copy of Windows 7 running in Hyper-V on the server. This allows the users to save files and settings to their computer as it can be setup so that users have a “persistent” 1 to 1 relationship to their virtual computer much like they have a 1 to 1 relation with their own computer. This also means that the user is connecting to an actual copy of Windows 7 and not Window Server 2008 R2 so applications compatibility is also better.

ATTENTION!!! A lot of the setting in this post refer to a NATIVE VDI implementation without the third party enhancements such as Citrix XenDesktop. If you are implementing Citrix or VMWare VDI solution some components of this post will not apply.

VDI can also be configured in two ways depending on your companies configuration.

VDI Pooled or Non-Persistent

This method is just has a bunch of identical Virtual Machines that a user will randomly connect to when they logon. Then when that user is logged off the session is scrubbed and there is no latent configuration change made. This method consume less disk space as changes are never kept. But it also has the disadvantage that the user has less ability to customize their computer such as installing their own application.

Pooled Virtual Desktop Drive Configuration

Image Reference http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/VIR312

As these computers are all but users normally have different requirements it is highly beneficial to also deploy virtualisation technology such as Application Virtualisation (App-V) and User State Virtualisation (USV). This allows each user to have a custom desktop configuration with their own set of applications with the same generic base OS. I am not going to go into App-V in this post but I do have more on USV later…

VDI Personal, Persistent or Private

This method has a bunch of Virtual Machines configured that have a persistent 1 to 1 relation with the user when they logon. This affinity with a specific VDI computer is configured via the users account under the new “Personal Virtual Desktop” tab.

Note: You have to be running Windows Server 2008 R2 service pack 1 for this new tab to appear.

If the computer is not started when the user is logged on the back end automatically starts it. When the user logs off the computer any changes made to the drive are saved for next time. This method has the advantage of allowing the users to be an admin of their own VDI computer to make changes and install whatever software they like. However the disadvantage of this is that it has to store all the changes for the users thus consuming far more disk space.

Personal Virtual Desktop Drive Configuration

Image Reference http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/VIR312

You may choose to use either or both configuration however which VDI method you chose will also affect the configuration you apply to the computers…

Note: For the rest of the document I will refer to the two types of VID computers as either “Pooled” or “Personal” however you can obviously substitute the name that you use to refer to these types of configurations for your implementation.

VDI also has the overall disadvantage of having additional system overhead as there are multiple separate copies of Windows 7 running at the same time on the same server all with their own memory space. Recently there has been some great improvements with the new Dynamics Memory feature in Windows Server 2008 R2 Service Pack 1 which has yield a 40% increase in density (Reference http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/VIR324 ). That all being said when you compare the user density between of RDS and VDI you STILL only get about half the number of users on the same hardware (See http://www.twitter.com/mkleef/status/136969504185004032 ).

Note: Before I begin however do note that this guidance mainly covers the configuration of the VM’s running in your VDI infrastructure and is not about configuring the underlying VDI infrastructure.

Below I will now go through a number of ways you can use Group Policy (and other ways) to configure your VDI computers for a optimal experience. Generally speaking however much like you do with Remote Desktop Services the theme of all these “optimisations” is disable, disable and disable… Remember you are trying to squeeze number of users onto you VDI hardware so turning off all the un-necessary components to reduce the per user overhead is the best way to do this…

As you can see from the image below the Disk IO on a VDI system is in extreme demand and constraint hit first when scaling.

Image Reference http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL309

 

Organisational Unit Structure for VDI

The Organisational Unit Structure for VDI computers will probably look something like the image below. This method keeps the OU structure relatively flat but it also means that you need to duplicate some setting in your normal workstations GPO’s. I think this is an acceptable trade-off as these polices will have Loopback enabled so you can apply user specific setting to these computers (more on this later). I also think  if you made the VDI OU a sub-OU of your Workstations OU it would be very difficult to troubleshoot issues with conflicted settings. This configuration would also unnecessarily give your normal workstation administrators control over the VDI computers that you normally want to control a LOT more tightly.

In your environment your VDI OU probably won’t be directly under the Top Level of the domain but this should still give you a template that you can use in any part of your AD. If you have read my previous blog posts Best Practice: Active Directory Structure Guidelines – Part 1 and  Best Practice: Group Policy Design Guidelines – Part 2 you may recognize that this design is similar to how I split Laptops and Desktops OU’s (You may also notice that I have also kept with a naming convention that adheres to these two blog posts as well.).  The reason why this looks similar is that just as workstations can be classified as either Desktops or Laptops so can VDI workstations be classified as Pooled and Personal, hence the similar design. This also means that for this structure to work ALL VDI computer accounts MUST be in either the Pooled or Personal OU. This would therefore make it invalid to have a compute account directly in the VDI OU.

Here is a description of the three main group policy objects that are applied in this configuration:

• Workstations VDI – This GPO will have all the setting that need to be applied to all your VDI workstations.
• Workstations VDI Pooled – This GPO will only have all the setting applied specific to your Pooled VDI workstations.
• Workstations VDI Personal – This GPO will only have the setting applied specific to your Personal VDI workstations.

Loopback for VDI

There are various user setting you may want to apply to your users when they logon to the VDI computer. Just as with Remote Desktop Service the use of the User Group policy loopback processing mode is the setting that allows you to apply these users setting.

Further on in this post I discuss many user setting that you might want to configure however if you don’t have any users setting configured in your VDI Group Policy Objects then there will be no need to enabled loopback.

Initial Computer Configuration for VDI (Native Only)

Note: This following configuration setting will only need to be applied if you are using a native VDI Implementation without third-party VDI software.

It is important that you configure the workstation for VDI as described it this guide Deploying Personal Virtual Desktops by Using Remote Desktop Web Access Step-by-Step Guide . Thankfully there is a PowerShell script that can do all the configuration changes for your VDI workstations image that you can download from http://go.microsoft.com/fwlink/?LinkId=184804 . However scripts are only a one time configuration and I like to re-enforce these changes with Group Policy where possible to ensure the configuration does not vary. Doing this also makes it easier to discover what changes have been made by running a GPResult report on the computer. Another advantage of having Group Policy makes all these changes is that all the configuration changes are automatically applied to your workstations when they are built making the process quicker and less likely to be forgotten.

Warning: Any additional setting via Group Policy could cause extra overhead so you many want to only be selective as to what initial computer setting you apply via Group Policy. For that reason you may want to consider running the PowerShell configuration script as a one time “Immediate” task on the computer via Group Policy instead of configuring all these changes individually.

If you chose to use Group Policy instead of a script (good on you) to setup your VID environment then make the following configuration change in the “Workstations VDI” Group Policy Object.

Enable Remote Desktop

You can enabled Remote Desktop using the Allow users to connect remotely using Remote Desktop Services setting. This will change the configuration of your computer to allow Remote Desktop Connections to the VDI workstation. However as you can see from the image below this does not open up the require firewall port (3389) to allow an incoming RDP connection.

Enable Remote Procedure Call (RPC)

To enable the Remote Procedure Call (RPC) feature all we need to do is use the Group Policy Preference Registry Extension to change registry key “HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\AllowRemoteRPC” to a value of 1 (see image below).

Adds selected users to the Remote Desktop Users group

You can configure the “Remote Desktop Users” group using the Group Policy Preference Local Users and Group Extension.

Add a Windows Firewall exception for Remote Desktop Services and Add a Windows Firewall exception for Remote Services Management

Now the two “Windows Firewall Exceptions” can be made by adding the following predefined inbound firewall exceptions under  “Computer Configuration>Policies>Windows Settings>Security Settings>Windows Firewall with Advanced Security”.

• Remote Desktop
• Remote Service Management
• Remote Desktop – RemoteFX (If required)

It should then look something like the image below:

The final step you need to perform on the workstation is to :

• Adds the proper RDP-TCP listener permissions for the RD Virtualization Host server

• Restarts the Remote Desktop Services service

 

However these steps are some what more difficult to perform as there is no Group Policy to make these configuration nor is the “Remote Desktop Session Configuration Host” tool loaded to make the changes via a GUI.

If you could load (or remotely connect this tool on Windows 7) it would look something like this by default…

So as much as a loath saying it you will need to resort to a script to perform the necessary configuration using the WMIC command.

To do this just copy the following script and put it on a server share that has the “Domain Computer” group granted read permissions.

wmic /node:localhost RDPERMISSIONS where TerminalName=”RDP-Tcp” CALL AddAccount “contoso\VDI Servers”,1
wmic /node:localhost  RDACCOUNT where “(TerminalName=’RDP-Tcp’ or TerminalName=’Console’) and AccountName=’contoso\\VDI Servers’” CALL ModifyPermissions 0,1
wmic /node:localhost RDACCOUNT where “(TerminalName=’RDP-Tcp’ or TerminalName=’Console’) and AccountName=’contoso\\VDI Servers’” CALL ModifyPermissions 2,1
wmic /node:localhost RDACCOUNT where “(TerminalName=’RDP-Tcp’ or TerminalName=’Console’) and AccountName=’contoso\\VDI Servers’” CALL ModifyPermissions 9,1
shutdown /r /t 0

Note: I have used the group called “VDI Servers” so you will need to create this group and add all your VDI server to this group. This way you can use the same script to configure all your VDI workstations.

You can then call this script as a once using the “Immediate Task (Windows Vista and later)” option in the Group Policy Preferences Scheduled Task Extension

Configure the task to run as the “SYSTEM” account so it has the permission to make the required changes and reboot.

Then chose the “Start a program” action and run the script where you have saved it on the network (remember that it must have “Domain Computer” read permission granted).

You have now configured group policy to automatically configured your Windows 7 workstations as a VDI ready computer once it is placed in the VDI OU structure.

However there are still a number of other suggested configuration settings you might want to apply to this computer…

 

Suggesting VDI Group Policy Settings

The next session shows a number of suggested Group Policy setting you should apply to you VDI configuration… Of course these are only suggestion/recommendations and you should take into consideration your own requirements before implementing these changes.

Disabling Services for VDI

Service are of course background tasks that run in Windows. These tasks of course takes some CPU,Memory and Disk overhead to run and therefore it is best that you disable all the non-essential services for your VDI workstations to squeeze in more users. To disable the services I like to use Group Policy Preferences Service Extension as it allows you to specify a custom service name that is not necessarily installed on the computer you are editing the group policy object.

The three service most obvious services I would recommend disabling are:

1. defragsvc – Defragmentation Service Account of course would generate a LOT of disk IO activity on the server and as you are probably running this on a fairly high end SAN or perhaps even on SSD’s then this is not required.
2. WSearch – Windows Search Service is another disk IO intensive service that likes to index all the files on a computer. Having this service enable also put a fairly high load on the system and therefore it is much better to turn this service off.
3. wuauserv – Windows Update Service is used to update the software on the computer. However this patch updates on a VDI computer are normally added via a master image or via an new image with the latest updates installed. Therefore this is another service that you will probably want to turn off.

You of course may have other inbuilt or third-part service that you want to disable and you can also do this by simply typing the short name of the “Service Name” text box when configuring a new service configuration item.

Turn Off System Restore

To Disable System Restore is another setting that prevents the VID computer form consuming more disk space. You can disable this setting  using the “Turn Off System Restore” policy setting.

Disable Offline Files

Disabling offline files is another way you can reduce your server IO load and disk footprint. You can do this via the “Allow or Disallow use of the Offline Files feature” group policy setting. You may want to configure this setting for only your Pooled VDI Workstations as there can be some performance benefit with having offline files enabled especially if the files you are access are via a slow network link.

Therefore I recommend that you Disallow for Pooled VDI computers to conserve disk space and Allow for Personal VDI computers so long as you have spare disk resources.

Disable Exchange Cached Mode

Disabled the Outlook Cached mode by using the “Use cached exchange mode for new and existing Outlook profiles” group policy setting would have to be the #1 setting that you should turn off for both Remote Desktop Servers and Pooled VDI Computers. This setting tries to download a cached copy of your entire inbox. This normally only happen during the first logon for a user to a computer, but because each logon to a Pooled VDI  computer is like a first logon then this will happen again… and again… and again… if it is not disabled.

That being said for Personal VDI computer there can be some advantage to having this setting enabled as it allows the users to still read their email even when the exchange servers is offline.

So this is another one that I recommend that you Disable for Pooled VDI computers and Enable for Personal VDI computers assuming you have enough disk space.

Enable Verbose Status Messages

I am a really big fan of configuring verbose status message’s (See Group Policy Setting of the Week 2 – Verbose vs normal status messages) as it gives the users the feeling that the computer is actually doing something rather than just “Loading desktop…” when logging on. You can enabled this via the verbose vs normal status messages setting under Computer Configuration\Administrative Templates\System.

Screen Savers

Screen savers can of course be very graphical and thus consume a lot of system resources. This means that your VDI server could get smashed when all the users go idle and the screensavers kick in…  Therefore we want to ensure that users only use the default “scrnsave.scr” screensaver that does nothing but display a blank background. To do this you need to configure the “Force specific screen saver” policy under  User Configuration>Administrative Templates>Control Panel> Personalization.

User State Virtualisation for VDI

It goes without saying that when users log onto a computer they of course don’t want to setup their environment every time. I have written a VERY extensive blog post about User State Virtualisation called Best Practice: Roaming Profiles and Folder Redirection (a.k.a. User State Virtualization). I strongly encourage you read this blog post as well if you are going to implement USV in VDI as most of these recommendations also apply for a VDI environment.

So why use User State Virtualisation with VDI?

Below are some points are to why you would want to enabled USV with VDI:

• Reduces disk IO as data files are read and written to file server over the LAN and not the local HDD.
• Reduces storage as the users files and setting are offloaded to another server.
• Enabling Roaming between physical and VDI computers
• Protect users files by storing store on File Server not VDI Server

As you can see there are many benefits with using USV with VDI however your decision to use USV may influenced by the method of VID that you implement… Of course as you are offloading the Disk IO from the local HDD to a file server on the LAN it is imperative that the file server is well connected via at least 1gbit low latency Ethernet connection.

Personal VDI

If the user has a Personal VDI workstations then USV may not be required as the computer will have saved all the setting and documents from the last time the user was connected. That being said there are still benefits with having USV enabled for a user on a Personal VDI workstations as it allows them to roaming the settings and files between the VDI environment and a real computer. Therefore you may consider VDI an option for users using a Personal VDI session.

Pooled VDI

If you use a Pooled VDI workstations as then it is very much like logging on to the computer for the first time. Therefore they will be required to setup there environment every time they connect (ANNOYING!!!). So it is somewhat imperative that you do enable USV for the users connecting to a pooled VDI configuration.

So how do I apply the USV GPO settings?

So if have decided to implement USV for your VDI user you will need to configure their profile path in their account properties (see image below).

The folder redirection Group Policy setting can however be applied either on the user accounts Organisation Unit OR via Loopback GPO on the VDI computers OU. To ensure complete roaming of the users setting and files I would definitely apply the folder redirection GPO’s on the users account that way they have a consistent user experience when logging onto a physical or a VDI computer.

Note: When deploying folder redirection it is very important that your redirection location is close (network wise) from your VDI servers. This is needed so that users can quickly access their redirected folders. This is even more important if the file server that host the redirected folder only support SMB v1 due to its poor performance on network links with high latency. This is less important if you have a Personal configuration with offline files enabled as the local caching can mitigate some of these performance issues.

Recommended: Due to the improved performance and saleability of the SMB v2+ protocol it highly recommended that your folder redirection file server is at least Windows Server 2008. It would also be highly desirable to make this server x64 bit as this will allow it to scale to a higher number of concurrent file connections.

User Only Folder Redirection

But if the only you have to implement folder redirection is to apply the setting on the VDI computers OU be aware that this might have some pretty big problem. If a user ever logs onto a non-VDI computer their roaming profile may not have any of the documents or files that the users had in the VDI. This can also lead to the users roaming profile growing very quickly as the documents folder on a non-VDI computer is now part of the users roaming profile. However when the user then subsequently logs back onto the VDI computer these documents will be hidden as they folder will again be redirected to the server.

• Users that roam between VDI and real computers will not have their documents move with them.
• If folder redirection is not implement but the roaming profiles are configured then the profiles will become very big and slow down the log on / log off process. This would also increase the disk footprint on the real and VDI computers.

VDI Only Folder Redirection

What you should ABSOLUTLEY NOT do is apply folder redirection on both the users OU and the VDI OU. Doing this could cause your users redirected folders to be moved from two different locations every time they logon greatly slowing down the logon process..

If your VDI infrastructure in a datacentre then you might find that their redirected folders will perform quite slow accessing their redirected folders. In this case you might want to setup a folder redirection on the user account and the VDI Computers OU. If you do make this configuration change make very sure you do not select the “Move the contents of Documents to new location” option as this will cause your users redirected folders to bounce all over the network every time they logon.

While this method would give the users fast access to their folder it would also mean that these files would not follow them when going between a physical and VDI environment.

Dual Configuration Folder Redirection

 

Group Policy setting for RemoteFX on VDI

RemoteFX is a new feature of Windows Server 2008 R2 that allow you you to stream full DirectX applications to your remote clients. This new feature can share the resource of any 3D graphics card in the server to get full hardware acceleration. Some of the other new features of Remote FX is the USB Device Redirection. This allows you to redirect pretty much any type of USB device that can be plugged into the remote client.

Image from http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/VIR312

But if you want to enable this feature you will need to enable the setting “All RDP redirection of other supported RemoteFX USB device from this computer” that is located under Computer Configuration>Administrative Templates>Windows Components>Remote Desktop Services>Remote Desktop Connection Client>RemoteFX USB Device Redirection.

Note: This setting requires a reboot after being applied.

However if you want to be somewhat selective with what devices (e.g. iPhones) you allow you users to plug into your VDI / RemoteFX environment then you can us the “Prevent installation of device that math any of these device IDs” under Computer Configuration\Administrative Templates\System\Device Installation Restrictions.

There are many other RemoteFX setting you can apply to your RemoteFX/VDI environment under Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment. However these setting will need to “tweak” for your own environment..

 

Group Policy Setting that you should NOT apply to VDI

So I have covered a few of the optimised group policy settings to your VDI computers however there are also some other group policy setting that you should avoid applying to your VDI computers.

Don’t applying Registry and File System permission via Group Policy as this will apply the permission every 18 hours (approx.) causing a MASSIVE load with IO on your VDI Server. Which is of course you now know a very bad thing…

DONT CONFIGURE THESE SETTING

If you do need to apply custom permission to the VDI computer then consider setting the permission in the master images or push a script out as a one time task VDI workstations.

Update: How to configure a home drive for VDI

If you want to configure your VDI users with a different home drive then there is a new group policy setting called “Set Users Home Folder” which allows you to specify what home drive the user receive. This setting can only be applied to the computer and as such makes it only useful for VDI environments when you want to give users a different home drive. For more information on this setting check out my other blog post http://www.grouppolicy.biz/2012/07/how-to-set-users-home-folder-via-group-policy-in-windows-8/

Summary

You may find that a lot of the setting you apply to your VDI systems are similar to the same policy you have applied to your Remote Desktop Services servers. This is quite true as just with RDS your VDI group policy setting revolve around reducing the overhead of the VDI workstations so you can squeeze the most out of your hardware… That being said, remember that if what you want is higher utilisation of your hardware you are always going to get more users on the same hardware using Remote Desktop Services…

Acknowledgements

I would like to give a big thanks to fellow MVP Darren Mar-Elia (a.k.a. @grouppolicyguy ) for helping me with this post… You can check out his web site at http://www.sdmsoftware.com and his “Optimizing Group Policy in Virtual Desktop (VDI) Environments” TechEd session at http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/WCL309

Back in the days of Windows XP IT administrators could disable the local administrator account on domain joined computers but still be able to use the account if they rebooted the computer into safe mode (see How to access the computer after you disable the administrator account ).

To log on to Windows by using the disabled local Administrator account, start Windows in Safe mode.

However this behaviour has change since Windows Vista (and 7) and now you are no longer able to logon to a computers local administrator account if it is disabled (see Built-in Administrator Account Disabled ).

On domain joined computers, the disabled built-in administrator account cannot logon in safe mode

This presents some challenges as IT administrator as sometime you still need to ability to logon to a computer using the local administrator. The most common scenario you need to do this is when you need to troubleshoot domain account issues (e.g. re-join the computer to the domain) when the AD computer account has been reset or deleted or the password has become out of sync and you get a workstation trust relationship issue (see below).

The problem is that the local administrator account is now disabled and due to the new behaviour of the account you can no longer log with it using safe mode.

The built-in administrator account is disabled by default in Windows Vista on new installations.

This of course makes it almost impossible to configure the computer into a workgroup so that it can then be re-added to the domain to fix the problem. Its even more difficult if you have BitLocker encryption enabled on your local hard drive.

It is possible that you could logon with a user with local administrator access using cached credentials however this is limited to the last 10 people that logged on (increasable to 50 if you change the CachedLogonsCount below registry key).

But even so, this would also mean you have to know the username and password of the account at the time they last logged onto the computer. This may be a bit hard to do as they may have changed their password a number of times since they logged on to that computer.

Unfortunately, it is also much more unlikely now that the normal local user of the computer has not been given local admin due to all the improvement with Windows 7 (e.g. UAC) that allows users to work with standard user permissions.

Now you might think the really obvious solution is to just enable the local administrator account and set a password in advanced using Group Policy Preferences (see below) so that you can use it when you need to however doing this has a few security issues.

However enabling the local administrator account means it can be used by anyone who knows the credentials and they could then use the account to remotely access any workstation on the network (not good). It also mean a normal user that knows the local admin credentials ( we would like to think they don’t but somehow they find out) could us them whenever they are presented with a specify credentials UAC prompt. So it’s pretty much a back door that anyone can use to get around the fact you spent all this time setting up their computers for them to not require local administrator access…

So to get around this issues you could just set the password on a regular basis using Group Policy Preference (see above image) however this also has a few problems as well… While setting the local administrator password is easy to do however it is stored in the SYSVOL as an encrypted string that is fairly easy to crack (see Passwords in Group Policy Preferences ).

A password in a preference item is stored in SYSVOL ….. it is not stored as clear text in the XML source code of the preference item. However, the password is not secured.

To help mitigate this I have also written an article that explain a way to more securely apply the new password to all the computers (see How to use Group Policy Preferences to change account Passwords ) but even if you did this on a regular basis you would still need to tell all the IT support staff what the new password is when you change the password and thus people quickly learn the local admin account credentials all over again…

Note: That all being said it is still a really good idea to set a password for the local administrator account as the default password is configured as blank.

The other solution you might think of is to boot the computer using a third-party tool that can reset and enable the local admin account (see http://www.bing.com/search?q=sethc.exe+%22windows+7%22+administrator+password&form=QBRE&qs=n&sk= ) however these tools don’t work if your local drive is encrypted with BitLocker nor are they supported from Microsoft (see Microsoft policy about lost or forgotten passwords ).

If you want help to break or to reset a password, you can locate and contact a third-party company for this help. You use such third-party products and services at your own risk.

So lets assume you have a computer that is no longer properly connected to the domain with a disabled local administrator account. The computers local system drive is BitLocker encrypted and and you don’t know the credentials of any other accounts that have previously logged on with local administrator permissions… What do you do?

So below I will show you how to enable the local administrator account so that you can at least still logon with the local administrator even if the account has been disabled…

How to enable a disabled local administrator account on a Windows 7 computer with BitLocker enabled

Before you begin you are going to at a minimum know the following information:

• The account name and password of the local administrator account.
• The BitLocker recovery key for the local system drive. (see instruction on how to get the key from here How to use Group Policy to save “BitLocker to Go” recovery keys in Active Directory – Part 1 )

Step 1. Boot the computer using the Windows 7 Installation media

Step 2. When prompted to “Install now” click the “Repair your computer” option at the bottom left.

Step 3 (optional). If your local computer hard drive is BitLocker is encrypted you will now be prompted to type in the recovery key (see below) and just follow the next couple of step that is appropriate for your situation.

Note: You may need to use the Recovery Key Identifier (e.g. A5103515) to find the correct encryption recovery key from Active Directory.

Note2: This step is only required if your local hard drive is encrypted using BitLocker drive encryption.

Step 4. After you have entered the correct recovery and unlocked the drive select the appropriate installation of Windows 7 that you wish to gain access to (You will probably only have one option to select).

Note: Remember the drive letter in the location column as you will need to use this later (Almost definitely going to be “(D:) Local Disk” ).

Step 5. From the System Recovery Options click on “Command Prompt”

Step 6. Now run “regedit” from the command prompt.

Step 7. Click on HKEY_USERS and then click on File > Load Hive

Step 8. Navigate to D:\Windows\System32\Config folder and select the SAM file then click Open

Note: The drive letter you use in the path above is the same as the the drive letter in the Location column in Step 4.

Step 9. Now type “SAM_TEMP” (or any value) in the Key Name text field and click OK

Step 10. Expand SAM_TEMP\SAM\Domains\Account\Users\000001F4 and double click on the “F” key.

Step 11. Change the value “11” in the first column, row 0038 to “10” and click OK

Before	After

 

Step 12. Click back on “SAM_TEMP” and then from the File > Unload Hive and Yes to confirm.

Step 13. Exit Regedit and close the Command Prompt and click Restart from the System Recovery Option menu

Done…

Summary

You will now be able to logon as the local administrator account by using the account name “.\administrator” and the password of the account (which you should already know). This will enable you to configure the computer into a workgroup and then re-join the computer account back into the domain but without having to resort to enabling a back door administrator account on the all the computers in your environment…

Now you might now be wondering what is the point of security is on Windows 7 (i.e. BitLocker and disabled local admin) if it is so easy to circumvent however you need to remember that for this process to work you still need to know the local administrator password and more importantly you will need to know the unique BitLocker recovery key… Obviously this makes it very important to have BitLocker drive encryption deployed otherwise it will make it very easy to break into pretty much any computer if you have physical access.

the best network software security measures can be rendered useless if you fail to physically protect your systems

I know this is not strictly a Group Policy topic however it is very closely related topic and one I feel that this is still well worth knowing for any IT administrator so you can configured a more secure environment…

Other References

How to configure Group Policy to use Data Recovery Agents with “Bitlocker to Go” drives – Part 2
How to use Group Policy to save “BitLocker to Go” recovery keys in Active Directory – Part 1

Windows Seven Forums: How to Enable the Built-in Administrator Account from WinRE

Recently, I have been working a lot with PowerShell to automate the creation of a full AD site OU structure (with Group Policy and all) along with all the necessary delegated permissions. One of the limitation of the out of the box AD PowerShell commands is there is no easy way (but apparently there is a really hard way) to delegate permission to Active Directory OU’s. Luckily Quest Software have helped a lot here and they have offered a set of FREE PowerShell commands for Active Directory called “ActiveRoles Management Shell for Active Directory” one of which is called Add-QADPermission which greatly simplifies the process of delegation security in AD.

The Add-QADPermission command can be used to add an DACL security descriptor permission to any AD object with a distinguished name such as users, computer or OU’s. Therefore you can use this to delegate permission to OU similarly to running a “Delegation of Control Wizard” in Active Directory Users and Computers console (see image below).

This wizard allows you to delegate some common tasks (see below) to your OU’s in you Active Directory however the permissions they apply are not straight forward simple permissions.

 

What I will show you how to do is how to perform some of the common delegation tasks that the “Delegation of Control Wizard” using a PowerShell command so you can automate the process for creating new OU’s in your environment. I know this is not strictly an Group Policy topic but it is one closely related and one I think many Group Policy admins will find useful.

The Command tasks I will show you are the one’s that I almost exclusively use when delegating permissions to Active Directory, they are:

• Create, delete and manage user accounts
  • and Groups
  • and Computers
• Reset user passwords and force password change at next logon
• Modify the membership of a group

Continue reading ‘Best Practice: How to delegate AD permission to Organisational Units using the PowerShell command Add-QADPermission’ »

In my previous article In this article Best Practice:Active Directory Structure Guidelines – Part 1 I spoke about some of the guidelines I personally use when developing an Active Directory OU structure. In this next part I will discuss some guidelines I use when designing a Group Policy Object infrastructure.

Ideally you should make the the Active Directory OU and GPO design decision together to best ensure that you have the most efficient design possible. However if you have an existing OU structure designed a lot of these guidelines can still be applied to most existing environments.

As in Part 1 these are simply guidelines that I use and should not be taken as hard an fast rules. I quite often finding myself having to break these rules due to real world conflicts or just because one rule might conflict with the other rule. If you do find your self in a situation where you are not sure which path to take try to chose the option that will result in the least administrative effort in the long term.

Continue reading ‘Best Practice: Group Policy Design Guidelines – Part 2’ »

I have been doing Active Directory and Group Policy work for a while now and I have developed my own set of rules that I try to use where ever possible. So below I have written down all my rules in no particular order for you to go over and use for yourself. You may only chose to use only some of these rules or you might want to use them all depending on your circumstance. This is a two part series where I will first talk about designing you Active Directory Organisation Unit structure and then in part 2 (Best Practice: Group Policy Design Guidelines – Part 2) I will discuss some more ideas for applying Group Policy to the OU structure.

I want to be clear that these are only guidelines and not rules that need to be strictly adhered to. In almost all case there are exceptions to these guidelines and you might even find your self implementing them in a hybrid approach. I intend for this web page to be updated on a regular basis as none of these rules are set in stone and thing obviously change all the time.

Continue reading ‘Best Practice: Active Directory Structure Guidelines – Part 1’ »