Group Policy Central

Removable memory sticks are the back door for data in any organisation. BitLocker to Go can do some way to controlling this vector however you might want to simple close off all access to removable drives for all your users. So if you are running Windows 7 you will be glad to know there are a heap of Windows 7 GPO setting that allows you to control access to your removable devices.

Even better there is a deny execute access policy setting prevents your users the running on BYO applications such as Firefox Portable and even some malicious software via USB sticks.

While most of the device types seem obvious, the WPD Device allows you to control access “to removable disks, which may include media players, cellular phones, auxiliary displays, and CE devices.”.

You can even configure the “Time (in seconds) to force reboot” which will enforce the change once it is applied to the computer.

These policy setting can be found under Computer Configuration > Policies > Administrative Templates > System > Removable Storage Access.

Its the best thing to control access to USB storage device since the invention of the hot glue gun….

Today I experienced Serendipity with the error “Unable to find a default server with Active Directory Web Services running.” in PowerShell with Windows 7. This message was occurring when trying to create some new OU’s using the New-ADOrganizationalUnit command. Initially I thought it was due to not having the required Active Directory Powershell commands installed but then I realised that the “Import-Module ActiveDirectory” command was loading find so that couldn’t be the problem.

About this time I then noticed a new blog post http://jorgequestforknowledge.wordpress.com/2011/12/12/the-active-directory-web-service-adws/ about the new Active Directory Web Services (ADWS) feature with 2008 R2 which explained why I was getting this message. The environment I was dealing with was a Windows 2008 only domain environment meaning that there was no ADWS for PowerShell in Windows 7 to utilise. This article explained that both PowerShell and the the Active Directory Administrative Center (ADAC) in Windows 7/2008 R2 used the WS-* protocols and therefore needed a ADWS server somewhere in the domain to work. Not having an ADWS DC in the environment meant that these tools would not work…

So to get around this issues you will need to either need to spin up a Windows Server 2008 computer to run the commands or apply the necessary KB’s to some of the domain controllers your environment to enable ADWS.

Update: I just learnt that the AD PowerShell commands are only supported on Windows 7/2008 R2.

The moral of this story is that its always good practice to make sure that your server and client infrastructure are upgraded together due to the advantages of the tight integration the two product have with one another.

Related KB’s:

Windows 7 clients cannot locate the Active Directory Management Gateway service that is installed on Windows Server 2003-based domain controllers

Windows 7 clients cannot locate the Active Directory Management Gateway service that is installed on Windows Server 2008-based domain controllers

Note: ADWS was included with Windows Server 2008 Service Pack 2.

If you have are one of the many people who have checked out my Best Practice: Roaming Profiles and Folder Redirection (a.k.a. User State Virtualization) post you probably know that roaming profiles can be super useful feature to implement. However over the years roaming profiles have got a bit of a bad wrap as sometime things can and do go wrong. In these case the IT administrator is usually left with no other option than to reset the users profile to solve a issue with their account.

Tip: Make sure that the issue is related to the users roaming profile by testing another account with the same or similar privileges on the same computer. If the other computer account also has the same issues or if the issues seems to does not follow them to other computers then it is highly unlikely it is a roaming profile issue.

So lets assume you have troubleshoot this issue for many hours and you are at your wits end about to rip out your hair (if you have any) and have decided to reset the users profile… how do you do it?

In Windows XP days you could just delete the users local and roaming profile files and the next time the user logged on they would generate a new profile. However if you do this in Windows 7 you will find that this no longer works…

So what is the correct way to reset a roaming profile in Windows 7?

Step 1. Open Active Directory Users and Computers and to the profile tab of the user account you want to reset. Now take note of the roaming profile path….

Step 2. Reboot the users computer that is having issues and logon with an account that has local admin and is NOT the account you are tyring to fix.

Step 3. Open control panel and type “Advanced” in the search field then click on “View advanced system settings”

Step 4. Click on the “Advanced” tab and under User Profiles click the “Settings” button

Step 5. Now select the user you want to reset the profile and press the “Delete” button.

Step 6. Press “Yes”

And now the local copy of the roaming profile is deleted you also need to remove the network copy…

Note: If you have implemented folder redirection as per my Best Practice: Roaming Profiles and Folder Redirection (a.k.a. User State Virtualization) then the vast majority of the users information will not be part of the users roaming profile. This means other than a few program setting the users is unlikely to lose any work. The exception to this is the AppData folder however if you are trying to preserve this folder as well note you may be copying over the issues that are trying to fix.

WARNING: Always be careful you have everything backed up before deleting any users profile.

Step 7. Before you log off that computer go to the path you noted in step 1 and delete (or rename) the roaming profile for that users on the network.

Note: You many need to take ownership of the folder before it can be deleted.

Tip: To avoid having to take owner ship of the roaming profile be sure you have enabled the  Add the Administrator security group to roaming users profiles setting.

How to fix the “You have been logged on with a temporary profile” issue in Windows 7

So… that was the easy way… But what do you do if just deleted the users profile files and now the users is “logged on with temporary profile” like you did back in the Windows XP days….

Step 1. Reboot the computer again and logon as the local admin.

Step 2. Open Regedit and go following registry key path:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Step 3. Find the Profile that has the ProfileImagePath of the users you are fixing and delete that entire key.

Step 4. Log off and logon as the user you are trying to fix.

TIP: If this is successful make sure you get the use to log off straight away so the new profile is save to the network which will then propagate to any other computer when then log on.

Hopefully this will have fixed your roaming profile issues and the users is now back up and running with a minimum of fuss… Of course some of the users personal settings may have been lost but hopefully a well managed SOE should allow them to run all the essential programs with little to no additional set up.

Source: I found the registry key trick from this TechNet Forum article http://social.technet.microsoft.com/Forums/en-US/w7itprogeneral/thread/5ec0b949-effa-4e30-ba09-dc948a4c7a8b

If you edit Group Policy on you local computer you will be glad to hear that Microsoft has just released the Remove Server Admin Tools update for Windows 7 Service Pack 1 which has an updated version of GPMC. This resolves the "The update does not apply to your system” error message if you had re-installed Windows 7 and loaded Service Pack 1 and then you tried to install RSAT.

Get it here http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7d2f6ad7-656b-4313-a005-4e344e43997d

Related Article: How to download and install the Group Policy Management Console (GPMC)

Update: Now that I have installed the final version of IE9 on 6 computers 2 of them needed to rebook so it would seem that it may or may not require a reboot. This seems to be dependent on what application you are running at the time. Therefore it would still be prudent to plan for a reboot but not always expect it to happen.

I have just install IE9 on a Windows 7 and a Windows Server 2008 R2 computer running Service Pack 1 and I was very pleased to see that in both cases it does not required a reboot to install. Previously I have installed IE9 on 3 Windows 7 computers that were not running service pack 1 however they all required a reboot to install IE9. Therefore it seems that with Windows 7 / 2008 R2 Service Pack 1 installed it is now possible to install IE9 without a reboot. (see images below).

Disclaimer: I have only seem this behaviour on one computer so far but I am testing it one more really soon. I have now repeated this process on a Windows Server 2008 R2 SP1 and Windows 7 SP1. It looks more likely that this option to install IE9 without a reboot is a new feature of Service Pack 1.

One of the dialogue boxes (see below) on Windows Server 2008 R2 Service Pack 1 during the IE9 install asks if you want to the installer to close your running programs to install it without a reboot. So if you select the “Close programs for me (I already save my work)” opting the browser will be installed without a reboot.\

( FYI: The screenshots below are from a computer running Windows Server 2008 R2 Service Pack 1 with the Domain Controller role installed and running. )

The next screen is the dialogue box during install of IE9. As you can see IE8 and the Explorer shell has been closed during the install but the OS has NOT rebooted.

After IE9 is installed the Explorer Shell is launched again still without interruption to the OS.

This is a huge deal as it means that it is likely that updates to the browser will be able to be installed without having to require a reboot of the OS. Now this may be a nice have for end users however this is a much bigger deal for Windows Servers as IT administrators as they can now patch what is the most vulnerable part of the server OS (the browser) without any down time. This should hopefully mean that IT administrators will not need to revert to installed “Server Core” versions of the server OS’s just to ensure that they don’t have to reboot them every patch Tuesday to keep them secure.

I know this is not specifically a Group Policy topic however this is a really super cool find that I just had to share with everyone…