Category Archives: Windows

Installing PowerShell with Package Manager on Windows Vista

Package Manager (Pkgmgr.exe) is a new Windows Vista command-line tool that you can use offline to install, remove, or update Windows packages. You can add a package, provided as a .cab file, to an offline Windows image.  Package Manager can also enable or disable a Windows feature, either offline or on a running Windows installation. And it is this last piece of functionality that we are going to be using here.

When you install the PowerShell package (KB928439) on Windows Vista it extends the list of optional features that can be selected to enable or disable. A lot of updates behave like this, eg. the Remote Server Administration Tools (RSAT) package. You can run optionalfeatures.exe to use a GUI to enable or disable the available features. But as mentioned you can also use Package Manager (pkgmgr.exe) to enable or disable the same features. The command to enable PowerShell is:

start /w pkgmgr.exe /iu:MicrosoftWindowsPowerShell

To disable PowerShell; run:

start /w pkgmgr.exe /uu:MicrosoftWindowsPowerShell

The start /w part is necessary because the default behaviour of pkgmgr.exe is to return immediately to the command line even when it is still performing its tasks. So to have the command prompt wait for the pkgmgr.exe process to finish before returning, add start /w.

Package Manager requires elevation to run, so either start it from an elevated prompt or be prepared to approve the elevation with the UAC prompt. To check the result of the Package Manager operation run echo %errorlevel% after Package Manager has finished.

To enable or disable other features have a look here for the names:

Windows Vista packages: http://technet.microsoft.com/en-us/library/cc722041.aspx

Windows Server 2008 packages: http://technet.microsoft.com/en-us/library/cc748930.aspx

 

How to manually transfer a user profile from one user to another

Introduction

A computer’s affiliation can change in many ways:

  • From workgroup to domain.
  • From domain to workgroup.
  • From one domain to another domain.

Common to these scenarios is that the user or users using the computer loose access to their locally stored user profiles. When a computer joins a domain it usually means the persons using the computer are given domain accounts to use to log on. The local profiles stored on disk are not associated with these new domain accounts and, even though it is the same person using the computer, he or she loose access to the profile and thus all their settings.

The same is true when the computer leaves the domain. Domain based account can no longer be used to log on to the computer and the persons who use the computer must start logging on with local user accounts. Again the profiles associated with domain based users are not available to the new local user accounts.

Likewise when a computer leaves one domain and joins another, the persons using it are given new accounts in the new domain and these accounts cannot access the profiles of the accounts from the old domain.

Needless to say, this is a big problem for the end-users. The profile stores a lot of settings and reconfiguring all of these is, at best, boring. So how can we mitigate this problem for our users?

HKEY_USERS, HKEY_CURRENT_USER and NTUSER.DAT

The registry consist of several, so called, hives; HKEY_LOCAL_MACHINE, HKEY_CURRENT_USER etc. To fix the profile problem of our users we need to learn about the HKEY_USERS and HKEY_CURRENT_USER hives.

HKEY_USERS

The HKEY_USERS subtree contains all actively loaded user profiles. HKEY_USERS has at least three keys:

  • .DEFAULT, which stores the profile used when no users are logged on to the computer (such as when the CTRL+ALT+DELETE logon prompt is displayed).
  • A subkey named for the Security Identifier (SID) of the current local user. This subkey contains the current user’s profile. If the user is logged on remotely, the data for the user’s profile is stored in the registry of the user’s local computer. The data in HKEY_USERS\SID also appears in HKEY_CURRENT_USER.
  • A subkey named for the Security Identifier (SID) of the current local user with the _Classes suffix. This subkey contains the current user’s Classes. The data in HKEY_USERS\SID_Classes is also contained in HKEY_CLASSES_ROOT.

 061008_2211_Howtomanual1

Figure 1 HKEY_USERS

In the picture above there are 5 loaded user profiles:

  • .DEFAULT
  • S-1-5-18 (NT AUTHORITY\SYSTEM) which is Local System.
  • S-1-5-19 (NT AUTHORITY\LOCAL SERVICE) which is Local Service.
  • S-1-5-20 (NT AUTHORITY\NETWORK SERVICE) which is Network Service.
  • S-1-5-21-1777867841-237173671-2295844794-1001 which is a local user account (called OldUser in this case).

If another user were to log on the computer, either through Fast User Switching or if the current user launches a program as another user, a new SID will appear under HKEY_USERS representing the registry hive of the new user. When a user logs off his or her hive is unloaded from HKEY_USERS.

HKEY_CURRENT_USER

The HKEY_CURRENT_USER subtree contains the user profile for the user who is currently logged on to the computer. The user profile includes environment variables, personal program groups, desktop settings, network connections, printers, and application preferences.

The HKEY_CURRENT USER subtree does not contain any data. It just stores a pointer to the content of the HKEY_USERS\ Security ID (SID) of the current user subkey. Therefore, the content of that subkey also appear in HKEY_CURRENT_USER, and it can be viewed and changed in either location. This subtree provides easier access to the data.

A new HKEY_CURRENT_USER subtree is created each time a user logs on. The data for the subtree comes from the profile of the current user. If no profile is available, the subtree is built from the user profile settings established for a default user, which are stored in %Systemdrive%\Documents and Settings\Default User\Ntuser.dat (Windows <5.1) or in %systemdrive%\Users\Default\ntuser.dat (Windows 6.0<).

 061008_2211_Howtomanual2

Figure 2 HKEY_CURRENT_USER

NTUSER.DAT

Each user’s registry hive is stored in the user profile in the NTUSER.DAT file. When a user is logged on the contents of NTUSER.DAT in that user’s profile directory is loaded into HKEY_USERS and also mapped into HKEY_CURRENT_USER. Inside a session the HKEY_CURRENT_USER always maps to the registry of the user who is logged on to that sessions. If a user starts a program as another user, the session created for that program, which has the other user’s security token, will see its own registry settings in HKEY_CURRENT_USER.

Profiles and permissions

As we have established the registry hive of a user is located in the users profile directory, and stored in NTUSER.DAT. But a profile contains much more than just a registry hive. It also consist of several directories containing everything from mail items to favorites.

 061008_2211_Howtomanual3

Figure 3 A typical user profile on Windows Vista

The user owning the profile is given full control access to it when it is created, both in the hive in NTUSER.DAT and in the file system.

 061008_2211_Howtomanual4

Figure 4 NTFS Permissions and registry permissions in a user profile

The HKEY_LOCAL_MACHINE hive contains a section for mapping user SIDs (and GUIDs) to the correct file system folder containing the profile. The path to the key is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.

 061008_2211_Howtomanual5

Figure 5 The ProfileList key

The ProfileList key contains a listing of every SID that has ever logged on to a computer and under the SID key the ProfileImagePath value points to where the profile for that user is located in the file system.

Note also the Sid value which contains a hex representation of the SID of the user owning the profile.

Domain joined computers also have a ProfileGuid key at the same level as the ProfileList key. The ProfileGuid key contains GUID to SID mappings for profiles.

Transferring the profile

From what we learned about the ProfileList key, transferring a profile to another user should be as easy as changing the ProfileImagePath value for the new user to point to the profile directory of the old user. Unfortunately, this will not work, even if the user receiving the profile is member of the local Administrators group. We have to change both the registry and NTFS file permissions to make the new user use the old profile. Here is what you do:

  1. Log on as the new user.
    This created a profile directory and entries under the ProfileList key pointing to this new profile directory.
  2. Log on as a user who is a member of the local Administrators groups. This cannot be either the user who’s profile we are transferring or the user who is to receive that profile.
  3. Change the NTFS permissions of the profile, giving the new user Full Control permissions on all files and subfolder. This is most easily done with an elevated command prompt and icacls.exe (or your permissions editor of choice).
    icacls.exe c:\Users\olduser /grant VISTA01\newuser:F /T /C /Q
  4. Load the NTUSER.DAT hive from the old user’s profile directory under the HKEY_USERS hive. Either use the GUI or this command:
    reg load HKU\test c:\users\olduser\ntuser.dat
  5. Grant the user receiving the profile Full Control to the entire hive. GUI or command:
    subinacl /noverbose /subkeyreg HKEY_USERS\test /grant=vista01\olduser=F
    (Note: There is a problem with SubinACL.exe that makes it not apply inheritance correctly. The above command circumvents this by adding the ACE to all keys.)
  6. Unload the hive. Either through the GUI or with this command:
    reg unload HKU\test
  7. Update the ProfileImagePath value under the new user’s SID in the ProfileList key, to point to the folder of the old user’s profile.
  8. Log on as the new user.
  9. When you are satisfied that the profile is working as expected you can delete the profile directory of the new user (which has only been used once), and rename the old profile directory to the username of the new user. Remember to again update the ProfileImagePath value if you do this.

Another way

Windows also has a more user friendly way to transfer a user profile from one user to another. That way is accessed through the System Properties window.

 061008_2211_Howtomanual6

The Settings button reveals a list of all the profiles stored on the computer:

 061008_2211_Howtomanual7

Here we can use the Copy To… button to copy a profile from one user to another.

 061008_2211_Howtomanual8

We also need to change who is permitted to use the profile, using the Change button at the bottom of the dialogue.

If the folder we are copying the profile to already exists, we receive a warning:

 061008_2211_Howtomanual9

After the process is finished you can log on as the new user with the old profile.

This method does all the changes that the first method does, except changing anything under the ProfileList keys. In this case we are copying the old profile into the new user’s profile folder and there is thus no need to change anything in the Registry. Except from that it does what I showed before; change the file permissions and the registry permissions inside NTUSER.DAT.

Note that this method also requires that you on as the new user at least once to create the profile directory and the keys under ProfileList in the registry.

Which method you prefer is entirely up to you, but I’ll go with no 1.

What do you lose?

These are the items in the old profile that you lose access to from the new user:

  • Data that is protected by the Data Protection API (DPAPI)
    DPAPI helps protect the following items:

    • Web page credentials (for example, passwords)
    • File share credentials
    • Private keys associated with EFS, S/MIME, and other certificates
    • Program data that is protected by using the CryptProtectData() function

More information

Installing printer drivers from a Windows Vista installation

Windows Vista comes with a huge collection of printer drivers in the box. If you need to install one or more of these drivers on a print server go to the Sharing tab of you printer and hit the Additional Drivers:

052708_2139_Installingp1

Check the driver you want to install and hit OK. Windows will ask you where the driver is located. Now browse to the following folder on the Vista machine:

C:WindowsSystem32DriverStoreFileRepository

This is where Vista keeps its driver store. For printers, the folders you are looking for start with prn. HP printer drivers are stored in the prnhp###.inf_######## folders for example. The tricky part is to determine which folder holds your required driver. Windows will not do a recursive search through the folder hierarchy so you have to point it at the correct folder for your printer. I usually do a search in the file contents for the name of the printer I am installing a driver for.

You can (of course) use PowerShell to do the searching for you. One of many possible commands is:

get-childitem -Path C:WindowsSystem32DriverStoreFileRepository -include *.inf -recurse | select-string -pattern ‘hp deskjet 980’

This will echo out the name of the file that contains the text hp deskjet 980, as well as the line in the file that contains the text.

Note: If you do this, you will notice that you get two folders containing inf files that match the text you searched for, provided that you searched for the name of a printer whose driver comes with Windows. Doing a compare of these files yields very few differences, and it seems to me they are for the same driver. You can compare two files like this:

fc.exe /U C:WindowsSystem32DriverStoreFileRepositoryprnhp001.inf
_65b34c6aprnhp001.inf C:WindowsSystem32DriverStoreFileRepositoryprnhp001.inf_884be055prnhp001.Inf

If you require x64 drivers you need to connect to a Vista x64 computer and if you need an x86 driver you connect to Vista x86.

Resolving DCOM 10016 Errors

For some reason I frequently encounter these DCOM errors on servers running SharePoint Services:

Log Name: System
Source: Microsoft-Windows-DistributedCOM
Date: 25.05.2008 15:50:23
Event ID: 10016
Task Category: None
Level: Error
Keywords: Classic
User: NETWORK SERVICE
Computer: server.domain.com

Description:
The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {61738644-F196-11D0-9953-00C04FD919C1} to the user NT AUTHORITYNETWORK SERVICE SID (S-1-5-20) from address LocalHost (Using LRPC). This security permission can be modified using the Component Services administrative tool.

If you see an error like this follow these steps to fix it:

  1. Figure out which COM Server application that is the problem. Run this command:
    reg query HKCRAppID<COM Server GUID from Event log entry>
    In this case the command would be:
    reg query HKCRAppID{61738644-F196-11D0-9953-00C04FD919C1}
    HKEY_CLASSES_ROOTAppID{61738644-F196-11D0-9953-00C04FD919C1}
    (Default) REG_SZ IIS WAMREG admin Service
    LocalService REG_SZ IISADMIN
    AuthenticationLevel REG_DWORD 0x6
  2. Open up the Component Services tool; dcomcnfg.exe
  3. Expand Component ServicesComputersMy ComputerDCOM Config
  4. Locate the failing component in the list, either by name or GUID, and select Properties.
  5. Open the Security tab.
  6. Depending on your error select Launch and Activation Permissions (as in this example), Access Permissions or Configuration Permissions.
  7. Add the required permissions:
    052508_1608_ResolvingDC1
  8. Hit OK twice to return to the Component Service tool.

The error should now be resolved.

How to install Windows Live programs on an unsupported OS

For some reason Microsoft has decided to not let us install any of the Windows Live programs; Messenger, Gallery etc. on Windows Servers or x64 editions of Windows XP. If you try to run the installer (WLInstaller.exe) on any of these OSs you see this error:
—————————
Windows Live Installer
—————————
Sorry, Windows Live programs cannot be installed on Windows Server, Windows XP Professional x64 Edition, or Windows operating systems earlier than Windows XP Service Pack 2.
—————————
OK
—————————
This is quite a problem for Terminal Server users.
To work around this do the following:
  1. Download and run the WLInstaller.exe on a supported OS.
  2. Select the programs you want and let the installer finish.
  3. Navigate to C:Program FilesCommon FilesWindowsLiveInstallerMsiSources or C:Program Files (x86)Common FilesWindowsLiveInstallerMsiSources if you are on x64 Vista.
  4. Copy the MSI files for the programs you need to the unsupported OS and install them. You will have to guess as to which MSI file is for which program, but that is doable.

The installation on the unsupported OS is completely automated, you will not be asked for any input.

Nice work Microsoft…

How to disable hibernation on a computer running Windows Vista/Server 2008

The hibernation feature in Windows, first introduces in Windows 2000, enables a computer to save its state in a hibernation file on disk. State in this context means the contents of the computer’s memory at the time of hibernation. The hibernation file, hiberfil.sys located on the boot volume, is the same size as the installed memory in a computer.
For portable computers, and maybe workstations, hibernation is a great feature, but probably not for servers. A server is not a machine you typically want to hibernate. As stated above the hibernation file is the same size as the installed memory, so if your server has 16 GB of memory you will see a 16 GB hiberfil.sys on your system volume. This is a big vaste of space for something you probably will never use. So how to disable the hibernation functionality and remove the hiberfil.sys file?
Windows Vista introduces a great new command line utility called powercfg.exe which enables you to configure every aspect of Power Management on a system. By using powercfg.exe with these parameters you can disable the hibernation feature and remove the hiberfil.sys file:
powercfg.exe /hibernate off
After this command has been execute Windows will remove the hibernation file automatically.
No all server systems enable hibernation, so you wil not always see the hiberfil.sys on all systems. Remember also to turn on the ability to see system files in explorer to be able to see the hiberfil.sys file.
This info is also documented in this KB article:
How to disable and re-enable hibernation on a computer that is running Windows Vista

IFilters and Windows Vista x64

I’m a big fan of x64, and that’s why I’m running Windows Vista x64 on all my computers (which support it). The support for x64 from hardware vendors and ISVs is very good, but unfortunately there are some things that are not ready yet. One of those things are IFilters. IFilters are used by the Windows Search service on Windows Vista, and by Desktop Search on Windows XP. There are a lot of IFilters out there, but unfortunately no IFilters compiled for x86 will work on x64. For me, that means that I loose the ability to index, among other things, TIFF files. That represents a major problem for me because I have a very large document library in TIFF format. The real kicker is that Microsoft’s own IFilters that are included with Office 2007, are still x86 and will not work with x64. According to Microsoft, they are working on a fix, but no one knows when this will be available. In the meantime, I have been able to track down a few x64 filters, e.g. the ZIP IFilter to index ZIP archives, and an x64 IFilter for PDF from Foxit Software.
Get them here:
UPDATE: Microsoft have just released a filter pack for several file formats. The packages comes for both x86 and x64. It is supported for installation on Exchange 2007, MOSS 2007, WSS 3.0 etc. Get it here:
Morgan

More on certificates; you cannot use the Certificate Services Web enrollment pages together with Windows Vista

Continuing my posts about the strange world of PKI and certificates.
Today I browsed over to my CA using my Windows Vista Ultimate machine. Only to receive this message:
ERROR:
The certificate enrollment page you are attempting to access cannot be used with this version of Windows. To enable Web certificate enrollment for clients running Windows Vista, your administrator must update all Windows CA Web enrollment pages. To learn more about this issue and the steps needed to update Web enrollment pages to support all versions of Windows, see:
Turns out that you have to copy the Web Enrollement pages from Longhorn Server (Windows Server 2008) to use Vista and web enrollement.

Nice tricks with the context menu in Windows Vista

For a long time, we have been enjoying a Windows XP Power Tool called “Command prompt here” on our directories’ and drives’ context menus. I recently discovered that Windows Vista has this functionality build in.

If you right-click your directory or drive while you press the SHIFT key, you get a few more choices. One of them is Open Command Windows Here. You also get Copy As Path which copies the path of the folder or drive to the clipboard. That is also very nice.

I wanted to have the command line available at all times so I had to do some digging in the Registry. The paths for the context menu actions for a directory and drive are the following:

Directory:
HKEY_CLASSES_ROOTDirectory
Drive:
HKEY_CLASSES_ROOTDrive

Under these you will find the shell key, it contains all the context menu actions associated with the drive or directory objects. E.g. cmd for command prompt, find for Search etc. The first thing to notice is that the cmd action is already there, so why isn’t it showing up all the time?

022207_2050_Nicetricksw1

The answer is the value you will find under the cmd key kalled Extended. If this value is present the action will only show up if you hold down the SHIFT key while you right-click. We want the prompt available at all times so we go ahead and delete the Extended value from both the Directory and Drive keys. Now the option is always available.

But what if we want an elevated prompt in the directory? We are all, of course, running User Account Control so we need to elevate to enable our Administator privileges when we need them. To have the option to open an elevated command prompt for your drives or directories we need to take some additional steps.

First we need a copy of cmd.exe, the command line program that we will set to always run elevated. Go to your system32 folder and create a copy of cmd.exe that you call cmd_elevated.exe or a name of your choice. Then select the properties for this new file and select that it should always run as an administrator.

022207_2050_Nicetricksw2

Next, you export the cmd action from the Directory and Drive keys in the registry. We are now going to create a new action that will launch the elevated command prompt. First merge the two exported registry files into one so that you can easily import both changes. Then you need to change the alias of the command so that our new item does not overwrite the old normal command prompt. The old alias is cmd, call the new one cmd_elevated or something. You will then have a file that looks like this:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOTDirectoryshellcmd_elevated]
@=”Open Command Window (Elevated) Here”
“NoWorkingDirectory”=””
[HKEY_CLASSES_ROOTDirectoryshellcmd_elevatedcommand]
@=”cmd_elevated.exe /s /k pushd “%V””
[HKEY_CLASSES_ROOTDriveshellcmd_elevated]
@=”Open Command Window (Elevated) Here”
“NoWorkingDirectory”=””
[HKEY_CLASSES_ROOTDriveshellcmd_elevatedcommand]
@=”cmd_elevated.exe /s /k pushd “%V””

Notice that the Extended key is missing from both the actions, that is so that the option will always appear. Now you can import the file and you will have two shiny new options whenever you right-click a drive or directory:

022207_2050_Nicetricksw3