Taken from Microsoft.com KB article at: http://support.microsoft.com/kb/816579

Note You do not have to start up the computer from the Windows Server 2003 CD-ROM to do an in-place upgrade unless the computer cannot start in the usual manner. If you can start the computer as usual, just start the in-place upgrade from within the operating system by running the WINNT32.exe file on the CD-ROM.

An in-place upgrade is the final alternative before you have to reinstall the operating system. Note that it takes the same amount of time to do the upgrade as to reinstall the operating system. Also, some of your customized Windows settings may be lost through this process.

To perform an in-place upgrade of Windows Server 2003, follow these steps:

1.  Insert the Windows Server 2003 CD in the CD-ROM drive or the DVD-ROM drive, and then restart the computer. Windows Setup begins.

2.  Press ENTER (to continue) when the Welcome to Setup window appears.

3.  Press F8 to accept the License Agreement.

4.  Use the arrow keys to highlight the Windows Server 2003 installation that you want to upgrade, and then press R (to Repair).

Note If the Setup program does not detect a previous installation but just continues to the partitioning screen, an in-place upgrade may not be possible. To detect an existing installation, the Boot.ini file must be correct, the installed registry files must be intact, and the build number must be the same. If these are not all true, Setup will not find the installation to do an in-place upgrade.

5.  Windows Server 2003 Setup performs an in-place upgrade of the existing installation. Follow the instructions on the screen to complete the process.

Part 1

http://advice.cio.com/brian_hopkins/11283/the_essential_ea_toolkit_part_1

Part 2

Part 3

Part 4

1)  Log into Juniper using a web browser... 10.91.xxx.xxx (xxx.xxx derived from Juniper #)  username=Administrator, password=BcbS3VPN#

2)  Click on "Network" --> "DHCP"

3)  Next to "bgroup0(10.91.xxx.xxx/28)", click on "Edit"

4)  Click on the "Custom Options" button in the lower right of the screen

5)  Click the "New" button

6)  Enter the custom options with the following information:  Code=186, Type=IP, Value=10.34.10.55 and click "OK"

Taken from Petri IT Knowledgebase at http://www.petri.co.il/how-to-disable-smb-2-on-windows-vista-or-server-2008.htm

Server Message Blocks Protocol (SMB) is the file sharing protocol used by default on Windows-based computers. SMB 1.0 was designed for early Windows network operating systems such as Microsoft LAN Manager and Windows for Workgroups, but until Windows Server 2008 and Vista, all Microsoft-based operating systems continued to use it more or less in its original format.

SMB 2.0 was introduced in Windows Vista and Windows Server 2008. SMB 2.0 is designed for the needs of the next generation of file servers. Windows Server 2008 and Windows Vista support both SMB 1.0 and SMB 2.0 in order to preserve backward compatibility.

Some of the enhancements in SMB 2.0, include:

• Sending multiple SMB commands in the same packet which reduces the number of packets sent between a client and server
• Larger buffer sizes
• Increased scalability, including an increase in the number of concurrent open file handles on the server and the number of shares that a server can share out
• Support for Durable Handles that can withstand short network problems
• Support of Symbolic Links

Testing done with copying large files between Windows Vista and Windows Server 2008, and then Vista to Windows 2003, have shown that by using SMB 2.0 the file copying was, in averege, 2 times faster than with older operating systems.

However, while SMB 2.0 seems to do a good job if BOTH client and server OSs support it, in some cases it will slow things down. The reson for this is that the version of SMB used for file sharing is determined during the SMB session negotiation. If both the client and server support SMB 2.0, then SMB 2.0 is selected during the initial negotiation. However, if they don't both support it, SMB 1.0 will be used to in order to preserve backwards compatibility.

The SMB protocol version to be used for file operations is decided during the negotiation phase. During the negotiation phase, a Windows Vista client advertises to the server that it can understand the new SMB 2.0 protocol. If the server (Windows Server 2008 or otherwise) understands SMB 2.0, then SMB 2.0 is chosen for subsequent communication. Otherwise the client and server use SMB 1.0.

When using the terms "client" and "server" in case of file and print sharing, it does not necessarily mean that a client-type OS such as Vista "always" connects to a server-type Os such as Windows Server 2008. Sometimes, a Vista computer will connect to another Vista computer, and in that case, the computer that is "serving" the shares is considered to be the "server".

Here's how SMB is used when related to SMB versions:

• When a Windows Server 2008/Vista "client" connects to a Windows Server 2008/Vista "server", SMB 2.0 is used.
• When a Windows Server 2008/Vista "client" connects to a Windows 2000/XP/2003 "server", SMB 1.0 is used.
• When a Windows 2000/XP/2003 "client" connects to a Windows Server 2008/Vista "server", SMB 1.0 is used.
• When a Windows 2000/XP/2003 "client" connects to a Windows 2000/XP/2003 "server", SMB 1.0 is used.

So, for troubleshooting purposes, mostly in an environment that has mixes operating systems, you might want to consider disabling SMB 2.0. You need to do so on both the "client" and the "server" operating systems. To disable SMB 2.0 for Windows Vista or Windows Server 2008 systems that are the “client” systems run the following commands:

sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled

Note there's an extra " " (space) after the "=" sign.

To enable back SMB 2.0 for Windows Vista or Windows Server 2008 systems that are the “client” systems run the following commands:

sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto

Again, note there's an extra " " (space) after the "=" sign.

In order to disable SMB 2.0 on the server-side computer, follow these steps:

Warning!

This document contains instructions for editing the registry. If you make any error while editing the registry, you can potentially cause Windows to fail or be unable to boot, requiring you to reinstall Windows. Edit the registry at your own risk. Always back up the registry before making any changes. If you do not feel comfortable editing the registry, do not attempt these instructions. Instead, seek the help of a trained computer specialist.

1. Run "regedit" on Windows Server 2008 based computer.
2. Expand and locate the sub tree as follows.

   HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters

3. Add a new REG_DWORD key with the name of "Smb2" (without quotation mark)

   Value name: Smb2
   Value type: REG_DWORD
   0 = disabled
   1 = enabled

4. Set the value to 0 to disable SMB 2.0, or set it to 1 to re-enable SMB 2.0.
5. Reboot the server.

Either of the following commands force a reinstall of VMware Tools

msiexec.exe /i "VMware Tools.msi" /qf REINSTALLMODE=vamus REINSTALL=ALL REBOOT="ReallySuppress"

msiexec.exe /i "VMware Tools.msi" /qf REINSTALLMODE=vomus REINSTALL=ALL REBOOT="ReallySuppress"

Select all friends-

javascript:elms=document.getElementById('friends').getElementsByTagName('li');for(var fid in elms){if(typeof elms[fid] === 'object'){fs.click(elms[fid]);}}

Taken from Dave Donaldson's blog at:  http://arcware.net/running-a-powershell-script-with-a-space-in-the-path/

Like with any new technology, getting started with PowerShell was not without a few hiccups. One of the first issues I ran into was how to properly pass script locations to PowerShell so that it could actually run them.

It turns out that PowerShell is a bit finicky in how it locates the script to run. You basically have two options for getting PowerShell to find and run your scripts:

1. Explicitly pass the full path of the script to PowerShell, or
2. Add your script location to the PATH environment variable so that you can just pass the script name

As simple as those sound, there's still a catch: if the path to your script contains a space, PowerShell won't be able to find it and will throw an error, unless you use some special notation. For example, below I'm trying to run a PowerShell script where the path has a space in it:

Enclosing the path in quotes works with your basic cmd.exe, but not in PowerShell. To get this to work in PowerShell, you need to use notation that follows this format:

"& '[full path to script]'"

I told you the notation was special. So now I have this, which will run the script just fine:

And there you have it. You can bet I've filed this one away permanently.

Example:

mstsc /v: Kaltec /w:640 /h:480