Transportable shadow copies previously were reserved for the Enterprise and Datacenter editions, but with this update, even the Web edition can take advantage of them.
This update also seems to fix a lot of other issues people have been seeing with paged pool exhaustion and VSS.
KB 913648
Excellent time saver, and fairly unknown still in the Windows world. Use this tool to migrate old 'hard-coded' server resources to a new consolidated DFS root.
http://www.microsoft.com/downloads/details.aspx?FamilyID=d00e3eae-930a-42b0-b595-66f462f5d87b&DisplayLang=en
Only 3 gotchas that I have run into from time to time is that you have to be running W2K3 Enterprise Edition to support the DFS consolidated roots and the server that is running the consolidated roots cannot be a domain controller. If you are running W2K3 RTM, you will need to download a DFS related fix (KB 829885). If you are running SP1, you are all set.
This goes along with the %0 trick I mentioned previously but if you are still using DOS style scripts for logons, whether to support older clients, or to keep an old setup around for historical purposes, make sure to call out the executable with a complete pathname and/or at least the correct extension.
This might seem like a really minor point but everytime the OS has extra "work" over a starved connection, performance will stall due to directory lookups and such.
So, instead of calling:
notepad newfile.txt
Use:
%windir%\notepad.exe newfile.txt
A side effect of stating 'notepad.exe' instead of 'notepad' is that the command prompt won't go looking for notepad.bat, notepad.com, or notepad.cmd, across the wire.
This makes a difference because any file extension mentioned in %PATHEXT% is cycled through until it finds a match.
This also helps in the case where a virus hijacks 'notepad.bat' somewhere in the path and you end up not running the intended executable. It is a bit of a security 'fixup' if you want to think of it that way.
Some might view this as overkill but when you are stuck logging into a domain over a cell phone data connection, you will thank me later. Ideally, you would want to convert your scripts to a VBScript or a PowerShell script, but that isn't always possible or feasible.
Many times I've seen logon scripts that will directly reference a certain domain controller's SYSVOL or NETLOGON share when running an executable or script that resides in the 'scripts' folder of the SYSVOL.
This defeats the purpose of having geographically located domain controllers if everyone is going to be pointing to a certain server everytime.
For instance if you have a DC in New York and a DC in London, but all your scripts refer to \\wsvr-dc-ny\netlogon\con2prt.exe, you will have a lot of traffic (theoretically) going over the wire to and from New York everytime someone logs in, in London.
So, as an example, if you are still using DOS style scripts, you would want to change:
\\wsvr-dc-ny\netlogon\con2prt.exe /c \\wsvr-ps-london\fax
to something that looks like:
%0\..\con2prt.exe /c \\wsvr-ps-london\fax
Why? It will use the logon server in London, if someone logged in, in London, assuming the system determines that it should use the London server as the logon server. You can always doublecheck by checking the %LOGONSERVER% environment variable.
Most people don't know about the "%0\..\" trick, so that is why I'm writing about this.
It also removes hardcoded server names in your scripts, which I try to do whenever I can, since it makes migrating to different naming schemes and other admin activities a lot easier.
This will basically work with any Windows OS that has the 'systeminfo' command.
systeminfo | find "Up Time"
You can think of 'find' much like 'grep' under Unix.
It will return something that looks like "System Up Time: 4 Days, 1 Hours, 53 Minutes, 36 Seconds"
If you are on an older OS, you can always do "net statistics workstation" and look for the second line which will say something like "Statistics since 5/18/2006 11:17 AM"
It won't be accurate 100% of the time, such as in the case where you have restarted the workstation service, but 9 times out of 10, it will be correct.
