Parameter
|
Explanation
|
/E
|
Copy all subdirectories, even empty ones.
|
/ZB
|
Use restartable mode; if access denied use Backup mode.
|
/R:0
|
Number of Retries on failed copies, in this case 0.
|
/W:0
|
Wait time between retries, in this case 0.
|
/XJ
|
Exclude Junction points
|
/NFL
|
No File List – don’t log file names.
|
/XD | Exclude selected directories; space delimited |
/XF | Exclude selected files; space delimited |
Monthly Archives: January 2009
Displaying the Volume GUID of a volume
The use of letters to identity volumes and partitions in Windows is something we have inherited from MS-DOS. Drive letters are still used today due to their ubiquity and for compatibility. However, the Windows operating system does not depend on them. Instead Windows uses a GUID to identify each volume or partition. (Windows Home Server, which is actually a custom version of Windows Server 2003 has done away with the use of drive letters completely.)This GUID is called the Volume GUID or the Unique Volume Name. The Volume GUID is assigned the first time the OS encounters a volume and it does not change. This ensures that Windows can always uniquely identify a volume, even though its drive letter has changed.
On systems with a lot of storage you will often run out of drive letters for your partitions and volumes. You can work around this by using mount points e.g., but you can also reference the volume by its GUID directly. This is actually the recommended practice in some situations. When configuring highly available virtual servers in Hyper-V with Windows Failover Clustering, for example.
So how do we find the Volume GUID? The easiest way I have discovered is by the use of the mountvol.exe utility. Running mountvol.exe without any arguments will show you help for the utility, but also the current Volume GUID to drive letter/mount point relationships.
To prove that the volume GUIDs really are the “true” path to the volume, copy one of the strings and past it into Explorer or the Run dialog.
Press enter and you will see the contents of the volume displayed.
(Notice the question mark by the drive icon in the navigation bar and the info pane.)
I have not been able to use the Volume GUID from the command line, but that is also the only limitation I have found. Not strange if you consider the command prompt’s origins.
You can also see all the volume GUIDs for every volume the OS has ever seen under the registry key:
HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
At this location you will also find the “regular” drive letter assignments. They have the form \DosDevices\<drive letter>. If you compare the data in this key for the Volume GUID and the DOS drive letter for a given volume, you will see that they match meaning that they point to the same volume.
Strangely enough, the Swiss army knife of disk and volume management in Windows; diskpart.exe can’t display the Volume GUID. This is something that will change in future releases, hopefully. Diskpart can, however, display another interesting piece of data which resembles the Volume GUID, namely the disk signature. Just as volumes have unique IDs, so do disks (or what Windows perceives as disks). The DETAIL command in diskpart will display the disk signature as the Disk ID. It is an 8 digit hexadecimal number.
The string \\?\ is present in all volume GUIDs and it tells Windows to turn off path parsing. Windows NT/2000/XP/Vista have a maximum path length of 255 characters. It is possible to use more that 255 characters by prefixing the path with \\?\. This enables you to use paths that are up to 32,000 characters long, and is called using the “wide” version of a function. The \\?\ itself is ignored as part of the path. E.g.:
“\\?\C:\Users\Aquaman\Documents\test.docx” will be processed as “C:\ Users\Aquaman\Documents\test.docx”
Various problems with the Volume GUID may occur under some circumstances making Windows unable to boot or access the volume. Some of these situations are documented here: http://support.microsoft.com/kb/959573
How to exit explorer.exe gracefully on Windows XP and Windows Vista/7
When you install a piece of software that integrates with the Windows shell, typically explorer.exe, you have to restart your computer to complete the installation. If the installer were to close explorer.exe the user would be left without a usable GUI. However there is a supported way of closing the shell process, perhaps saving you from a reboot when installing software. Or just giving you something to test and play around with.
Windows Vista
Press the Start button, and while holding Ctrl+Shift, right-click any empty area of the menu, or the power or lock buttons. You will see this context menu:
Hit Exit Explorer to exit the shell process.
Windows XP
Open the shutdown dialog, Log Off…/Shut Down/Restart, and while holding Ctrl+Alt+Shift hit the Cancel button. Explorer will exit cleanly.
So now what?
OK, so we have made our shell exit. So how do we control the computer now? Any applications you had running while the shell was running will still have their windows on your desktop, but you will not be able to do much with them. We need to restart the shell process. How, you say? Simple. Just bring up Task Manager (Press Ctrl+Shift+Esc) and select New Task… (Run) from the File menu. Enter explorer.exe and your shell will restart.
More info on Aaron Margosis’ Blog:
http://blogs.msdn.com/aaron_margosis/archive/2007/07/17/how-to-cleanly-stop-explorer-exe-on-windows-vista.aspx
Using WinPE and ImageX to recover from a failed hard drive
EntryType : Error
EventID : 11
Message : The driver detected a controller error on DeviceIdeIdePort0.
Category : (0)
CategoryNumber : 0
ReplacementStrings : {DeviceIdeIdePort0}
Source : atapi
TimeGenerated : 11.01.2009 20:47:12
TimeWritten : 11.01.2009 20:47:12
UserName :
- Download and install Windows Automated Installation Kit
This package contains WinPE, which I use to capture and apply the WIM image, as well as the utility used; ImageX. - Create a bootable WinPE CD-ROM containing ImageX.
ImageX.exe is the only file I neede to add that was not already included in WinPE. - Boot the WinPE CD.
- Run ImageX:
imagex /capture c: d:myvistabackup.wim “Emergency Vista Backup” /compress none - Replace the failed drive.
- Boot WinPE again.
- Run Diskpart to create a new partition on the new drive and set it active:
diskpart
select disk 0
clean
create partition primary
assign drive letter=c:
active
exit - Format the new partition:
format c: /q /y - Apply the image:
imagex /apply d:myvistabackup.wim 1 c: - Update the Boot Configuration Database (BCD):
bcdedit /set {bootmgr} device partiton=c:
bcdedit /set {default} device partiton=c:
bcdedit /set {default} osdevice partiton=c: - Reboot
Fixed some problems with the blog
- Using Wireshark network analyzer to decipher SSL traffic.
- Configuring ISA Server 2006 to publish Outlook Anywhere using Kerberos Constrained Delegation. (Judging by the amount of spam comments on the first post on this topic, this should be popular.)
- A few more I can’t remember right now