HOW TO: Replace WinRE with DaRT 7.0 locally and enable remote connections before supplying local administrator account information

This guide will take you through the necessary steps to create a DaRT 7.0 installation locally (replacing WinRE) and not having the user need to enter the password for a local administrator account before having the remote connection start. Basically this means that a user can press F8 during boot and choose “Repair your computer” and have someone remotely taking control over their machine and fixing problems which previously required physical presence of IT staff.

Note: There is information on how to do this in official MS documents for DaRT 7.0 but you have to do a lot of reading between the lines so I wanted to take the moment to do a complete documentation on how to accomplish this.

Background on WinRE and local admins

Some basic information about WinRE is that whenever you start WinRE (and that includes DaRT 7.0) when it is located on the machines disk it will always ask you to supply a local admin account information. This is not the case if you boot WinRE or DaRT from USB, DVD, CD or via PXE boot, then you do NOT have to enter a local admin account to gain access to the system. Potential security issue here I might add.

Step by step solution

The dilemma with DaRT and remote connections is that we cannot in most cases let the users know the password of our local administrator account so what we can do is to start the remote connection as soon as possible when DaRT boots. So here is what you need to do to achieve this:

1. Go through the DaRT Recovery Image wizard and create your DaRT.iso. Then extract this ISO file and copy boot.wim which can be found in the sources folder to C:\DaRT and rename it to winre.wim.

2. Start a cmd.exe with administrator privileges.

3. Create a folder called C:\DaRTmount

4. Run the following command (on one line and with no space between “mount-” and “wim”:

dism /mount-wim /wimfile:C:\DaRT\winre.wim /index:1 /mountdir:C:\DaRTmount

5. From the same command prompt, type “notepad” to start Notepad and then browse to C:\DaRTmount\Windows\System32 and open winpeshl.ini. Make sure that this is entered into the winpeshl.ini and then save the file:

[LaunchApps]
"%windir%\system32\netstart.exe -network -remount"
"cmd /C start %windir%\system32\RemoteRecovery.exe -nomessage"
"%windir%\system32\WaitForConnection.exe"
"%SYSTEMDRIVE%\sources\recovery\recenv.exe"

6. When the file is saved make sure that you have closed notepad and also all instances of Windows Explorer (yes, the following command might fail if you have Explorer windows open) run the following command:

dism /unmount-wim /mountdir:C:\DaRTmount /commit

7. After the image has been saved you need to replace the existing Windows recovery environment with your customized DaRT installation.

8. Start by making sure that you show hidden and operating system files (via Windows Explorer – Organize – Folder and search options – View).

9. Go to C:\Recovery (if you get “access denied”) you need to modify the access control list, add your account or everyone full control to this folder.

10. Now scroll down the folder structure until you reach where winre.wim is located. Now copy your modified winre.wim from C:\DaRT to this location. Remember to set the ACLs back on the recovery folder when you are finished, that is if you modified them.

11. Test by booting the machine and press F8 just before Windows starts loading and you will get “Repair your computer” option. Choose that and see how the Remote Connection is started along with the prompt for local administrator password, giving your users a chance to let you connect and then giving the IT staff enter the password.

12. Done!

Blog post highlights of 2011

Another year has passed by and I would like to take the opportunity to share some of my most interesting blog posts during the year. First off is Busting the myths: Windows 7 require Windows Server 2008/2008 R2 domain controllers and raised functional levels.

Second off is the guide I wrote up the other day on a very hot subject, how to handle user group policy settings when migrating for instance from Windows XP to Windows 7. Third comes the strange things UAC may cause, and this one is about mapped network drives not being accessible when cmd.exe is run with admin privileges although the same user account.

One last thing I want to highlight is that although it is actually from last year but still worth noting, this little tip on how to very easily discover performance issues such as drivers making going to sleep/resume from sleep slow, apps making your machine start and shutdown slower etc, HOW TO: List performance issues with your Vista or Windows 7 machine.

HOW TO: Handle user group policy settings in multiple OS environments

This is a very common question and one that I would say all companies migrating to Windows 7 has experienced. The scenario is how do we handle user group policy settings when we have multiple operating systems such as Windows XP and Windows 7 or in the future also introduce Windows 8?

First I strongly recommend that you do not reuse the user configuration for Windows XP for Windows 7. Group policies tend to grow over time and at most customers I have encountered a lot of rubbish in the old configuration. Starting over and migrating only what is needed minimize the risk for problem and makes the configuration slicker and more easy to manage in the long run.

But how do we make sure that users get one configuration when they log in to for instance Windows XP and another configuration when they log in to a Windows 7 or Windows 8 machine? Well, let’s have a look at the options including pros and cons followed by recommendations from the field.

1. Security group filtering

• Pros:
  - Require no change in OU structure/move of users.
• Cons:
  - Requires a lot of management and make it hard to administer.

2. Separate users into a new and old OU

• Pros:
  - Easy to do if you have very few users and no dependencies to other services or applications.
• Cons:
  - Not a manageable solution in an environment with many users.
  - There are often apps or services that rely on the users being in a certain OU which is making it hard to move users without affecting other services.

3. WMI filters

• Pros:
  - Keep the users in the OU they are today not affecting other services or apps that rely on users being in a certain OU.
  - A longterm investment in making it easy to introduce new operating system versions.
  - Quick determination (WMI is often known to be real slow but this particular query is not performance intensive).
• Cons:
  - Need changes for existing environment, i.e. for instance Windows XP user configuration.
  - Could make group policies not being applied due to problems with WMI repository or related services.

4. Loopback processing

• Pros:
  - Keep the users in the OU they are today not affecting other services or apps that rely on users being in a certain OU.
  - Very reliable solution.
• Cons:
  - If not Replace mode is used you need to handle current configuration.
  - Might become a mess to troubleshoot and maintain if naming and config is not done consistent and clear.

Recommendations from the field

In my professional opinion the only real alternatives are WMI filters or loopback processing and sometimes I recommend WMI filters for separating user settings depending on what operating system they are logging in to and sometimes I recommend loopback processing. It depends on the environment and needs for the customer. Many times moving the user accounts around is not an alternative but consider that a very good alternative if possible to accomplish.

How do I implement it in my environment?

1. WMI filters

In the Group Policy console you create multiple WMI filters for for instance Windows XP and Windows 7. You then set each WMI filter respectively on each GPO containing user settings for each operating system. NOTE: Always test it out before applying this configuration to your existing environment. Also note that this does not affect performance to any noticeable amount of time.

Windows XP:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "5.2%" AND ProductType ="1"

Windows 7:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.1%" AND ProductType ="1"

Windows 8:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE "6.2%" AND ProductType ="1"

Basically the version is the OS version as we know it and the ProductType=1 means that it is a client operating system.

So you will end with for instance one GPO named “User Configuration – Windows 7″ which have the WMI filter for Windows 7 machines set and one GPO named “User Configuration – Windows XP” which have the WMI filter for Windows XP set.

2. Loopback processing

A prerequisite for using loopback processing is that you keep computers in separate OUs, for instance XP computer accounts in one OU and Windows 7 computer accounts in another OU.

You then create GPO objects in the OU for Windows 7 in our example and configure the user settings there. As I think you should always separate Computer and User configuration GPO:s I would say that you in a Computer configuration policy in that same OU set this setting for the user settings to be applied when users log into Windows 7 machines:

Policies – Computer configuration – Administrative templates – System – Group Policy and there set “User Group Policy loopback processing mode” to Replace or Merge, depending on what you want to achieve and how you want to handle your current configuration. Replace mode is recommended as you will have a hard time maintaining and troubleshooting the configuration otherwise.

Done! When users log on to your Windows 7 machines they will get the user settings you have defined in the user configuration GPOs located in the Windows 7 machines OU in our example.

System Locale not set correctly causing SQL Server to fail installation with error “Performance counter registry hive consistency”

Hit an interesting issue when I was about to do a MAP (Microsoft Assessment and Planning Toolkit) scan at a customer. When installing SQL Server Express 2008 R2 I hit a problem  and got the error message “Performance counter registry hive consistency” = FAILED installation.

The problem was that the System Locale was not set properly for my Windows 7 box. Fix was to set it under Region and Language – Administrative tab and there set the system locale and restart the machine. After that the SQL Server installation went fine!

Microsoft Assessment and Planning Toolkit SQL limits and recommendations

When you are about to run MAP (Microsoft Assessment and Planning Toolkit) assessment it comes by default with a SQL Server 2008 R2 Express database. This has a limit of a database of 10GB. This is in many cases not a problem but in larger environments it can be.

My experience tells me that a 10GB database is good for keeping data for about up to 10 000 machines. If you hit the limit the best option is to use a fully licensed SQL Server which has no limits on the database size.

The second option is to divide the scans to say for instance different OUs and switch between multiple databases. This does not give a combined report in any way so it is definitely not the best option but it will get you there.

The latest version of MAP 6.5 can be downloaded from Microsoft Download Center.