While I was mindlessly surfing I came across a few interesting links I thought I’d share.

Justin Ho posted about the D-Link router emulator pages and Blue Lock.

The D-Link router emulator pages show you what the configuration pages look like for various models of D-Link devices, which makes it nice when remotely supporting friends and family and you can’t see what they see.

Blue Lock is an open source program that locks your Windows PC if a particular Bluetooth device is not detected. For example, if you register your Bluetooth mobile phone with the program but then move away from your desk, the program will detect your phone is out of range and automatically lock your system, requiring the password to be entered to reactivate the system. Full Delphi source code is provided.

Dan Cunningham has released version 1.01 of his Workstation Migration Assistant program. As Dan puts it,

“The Workstation Migration Assistant is a visual wrapper for Microsoft’s User State Migration Tool, designed to simplify the capture / restore process for your end-users, and at the same time being highly configurable so that it can be customised to suit your organisations needs. Some of it’s features include:

• Migrate via a pre-defined network storage location, external USB drive, or user-specified location. USB drive detection is automatic, and you can decide whether drives below a certain size are ignored (ie, memory sticks)
• Optional Hard Disk Health Check will run a CHKDSK prior to capture and fix errors if any are found
• Optional Encryption using a pre-defined company encryption key, or per-user customised encryption (for highly sensitive data that can’t be stored on a server without being encrypted)
• Use different configurations for “XP Only” (XP > XP) migrations via Standard (XP > Vista and Vista > Vista)
• Automatically run pre and post-capture / restore scripts and programs (very useful to further configure machine settings)
• Migrate domain only accounts, or domain and local
• Automatically exclude certain domain or local accounts from the migration
• Automatically send log files to an e-mail address via SMTP after the migration
• On-screen status during every stage of the migration, including ETA
• Option to limit migrations to a certain size, i.e. if over 20GB of data to backup, then fail and inform user. This is also overridable
• Automatic checks for USMT installation and optional download
• Command-line automation
• Super-pretty UI “

Cameron Fuller writes about his experience with Adding the first Windows 2008 DC running Server Core to a Windows 2003 Domain. I’ve previously used his data posted in Active Directory Stress Testing and Memory as a basis for sizing my virtual domain controller’s memory allocation.

The Sean Blog discusses diagnosing Windows crashes (blue screens), and mentions the Crash Analyzer Wizard. I’ve played with this tool before, since we get it with our Microsoft Volume License agreement. The wizard is a component of the Microsoft Diagnostics and Recovery Toolset, which is available from Microsoft as a 30 day evaluation.

While being an unwilling participant in an excessively long conference call I was able to get Powershell up and running on my Server Core box, thanks to Dmitry’s detailed instructions.

Of course this is an unsupported configuration, which means Microsoft won’t help you if you experience problems.

If you’re a command line type administrator like myself you’ll want to check out Mark’s Mark’s DNS Server command line cheat sheet. He’s summarized the Windows Server 2008 CLI commands relating to DNS administration.

You’ll need to become intimately familiar with administering DNS via the command line if you’re running the Server Core version of Windows 2008.

Windows 2008 Server Core uses the SCregEdit.wsf script found in C:\Windows\System32 to configure Automatic Updates behavior.

To view the current Automatic Updates settings, from the command prompt type:

c:\windows\system32\scregedit.wsf /AU /v

The following values correspond to the response generated by the scregedit.wsf script.

1 = Automatic Updates Disabled

4 = Automatic Updates Enabled

To enable Automatic Updates, from the command prompt type:

c:\windows\system32\scregedit.wsf /AU 4

To disable Automatic Updates, from the command prompt type:

c:\windows\system32\scregedit.wsf /AU 1

Note:

I’ve seen all over the Internet people posting that the syntax to enable AU is:

Cscript c:\windows\system32\ scregedit.wsf /au /4

I can tell you for sure using the syntax on the line above will generate the following error:

“Parameter 1 : Parameter type mismatch expected DWord.”

Make sure there is no leading slash before the numbers 1 or 4. There is a slash before the letter v when viewing current AU settings.

By default the Windows 2008 Server Core screensaver will activate after 600 seconds (10 minutes) of inactivity.

To change the amount of time the screensaver waits to activate, edit the following registry key:

HKEY_CURRENT_USER\Control Panel\Desktop\ScreenSaveTimeOut

I changed mine from 600 seconds (10 minutes) to 1200 seconds (20 minutes).

Sander has several other Desktop related settings you can configure for Server Core on his blog.

Windows 2008 Server Core uses the SCregEdit.wsf script found in C:\Windows\System32 to configure Terminal Services (TS) behavior. TS is the method of remote controlling your Server Core system through Remote Desktop (RDP).

To view the current Terminal Server settings for Vista/Windows 2008 clients, at the server command prompt type:

c:\windows\system32\scregedit.wsf /AR /v

The following values correspond to the response generated by the scregedit.wsf script.

1 = Terminal Services Disabled (remote access disabled)

0 = Terminal Services Enabled (remote access enabled)

To enable Terminal Services access from Vista/Windows 2008, at the server command prompt type:

c:\windows\system32\scregedit.wsf /AR 0

To disable Terminal Services access from Vista/Windows 2008, at the server command prompt type:

c:\windows\system32\scregedit.wsf /AR 1

Note:

The /AR setting applies to Windows Vista/2008 machines. If you want to allow Terminal Services connections to the Windows 2008 server from Windows XP machines, you have to use the /CS switch.

To view the current Terminal Server settings for Windows XP clients, at the server command prompt type:

c:\windows\system32\scregedit.wsf /AR /v

To enable Terminal Services access from Windows XP, at the server command prompt type:

c:\windows\system32\scregedit.wsf /CS 0

To disable Terminal Services access from Windows XP, at the server command prompt type:

c:\windows\system32\scregedit.wsf /CS 1

You could also edit the registry directly to enable Terminal Services using the same registry entry I wrote about when describing how to enable remote access for Windows XP machines remotely.

Finally you will need to create a hole in your server’s Windows Firewall for inbound RDP traffic on port 3389. KB 947709 details how to use the netsh advfirewall firewall command to configure the firewall in several different ways. I suggest running the following at the server command prompt:

netsh advfirewall firewall set rule group=”remote desktop” new enable=yes

To shut down a Windows 2008 Server Core System, at the command prompt type:

Shutdown -s -t xx

where

-s = shut down

-t xx = time to wait before shutting down in seconds, where xx =0 to 600

To shut down a Windows 2008 Server Core System immediately, at the command prompt type:

Shutdown -s -t 0

where 0 = wait zero seconds (shut down immediately)

To restart a Windows 2008 Server Core System, at the command prompt type:

Shutdown -r -t xx

where

-r = reboot

-t xx = time to wait before shutting down in seconds, where xx = 0 to 600

To restart a Windows 2008 Server Core System immediately, at the command prompt type:

Shutdown -r -t 0

where 0 = wait zero seconds (reboot immediately)

Windows 2008 Server Core is a minimalist installation of Windows Server 2008. It must be managed from the servers console command line or remotely via Terminal Services.

In previous versions of Windows Server, NTbackup.exe was the program used for creating system backups. NTbackup.exe has been phased out and has been replaced in Windows 2008 by Windows Server Backup, wbadmin.exe. NTbackup is still available as a separate download in Windows 2008, only for backwards compatibility for restores, so don’t bother trying to use this legacy tool to create backups.

Since the Server Core installation only installs files that are absolutely essential, we’ll first have to install Windows Server Backup. The following command is case sensitive, so type it carefully from the server console:

start /w ocsetup WindowsServerBackup

Now that the Windows Server Backup program is installed, we can start making backups to remote machines.

wbadmin.exe start backup -backuptarget:\\SERVER\SHARE -allCritical -VSSfull -quiet

will create a backup of the entire system and save it to \\SERVER\SHARE, which is a share on a remote machine. Notice that a UNC path is required rather than a mapped drive.

Normally you will be prompted to answer Y/N to “Do you want to start the backup operation?” before the backup begins, but the -quiet command hides this prompt.

To create a System State Backup and save it on the D Drive, use the following syntax:

wbadmin.exe start systemstatebackup -backuptarget:d:

There are a few rules you need to remember about backups in Windows 2008. First, you can’t create a System State Backup on the server’s C Drive. You’ll receive the following message:

ERROR – The location for backup is a critical volume.

I used to be able to create System State backups in Windows 2003 and save them to the C Drive. This was useful for servers that had only one partition, since I’d move the System State backup to a flash drive after it was created. Luckily, KB 944530 describes a registry entry you can create to enable system state backups to critical volumes.

To enable the system state backup files to be targeted to critical volumes, you must set the value of the AllowSSBToAnyVolume registry entry under the following registry subkey:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wbengine\SystemStateBackup\

Set the value of this entry as follows:
Name: AllowSSBToAnyVolume
Data type: DWORD
Value data: 1
Note When this value is set to 1, system state backups to any volume are enabled. To revert to the default behavior, set the value to 0.

The next rule, which I find to be particularly ridiculous, is that you cannot save System State backups to a remote share on another server. When I attempted to do this I encountered the following message:

“Creating a system state backup to a shared network folder is not allowed. To store a system state backup on a shared network folder, first run the backup to a local volume and then copy the backup to the shared network folder.”

Sounds great in theory, but like I said before, if you only have a C Drive and no other local volumes, unless you hack the registry the only way you can backup the System State is to do a complete system backup.

The third rule is you can only backup entire volumes, which means no choosing which folders and files are backed up. I find this odd, since I often have folders that I don’t want to ever backup, like temp and cache directories.

Finally, you cannot backup to tape using Windows Server Backup. I’m not really affected by this since I’ve been using disk-to-disk solutions for quite a while now. I can see how this caveat may mess with some admin’s backup strategy, especially those used to keeping long term tape archives.

I had just performed my first Windows 2008 Server Core installation on VMware Workstation, and wanted to install the VMware tools to see if the VMs performance would increase.

Logged in as Administator I started installing the tools the normal way – from inside VMware Workstation I selected VM – Install VMware Tools.

Nothing happened. Since VMTools is a GUI installation, and Server Core has no GUI, I was pretty unsure of how to proceed.

I came across Jeff’s post that pointed me in the right direction. Selecting VM – Install VMware Tools was correct, but I then had to change to D:\ (my DVD drive letter) and type setup to start the installer.

The installer was actually GUI based, which I thought was weird. It was pretty much a Next – Next – Next type installation.

I didn’t have to kill RUNDLL like Jeff did. Maybe this was a bug that was fixed in the RTM version of Windows 2008.

Geert says the syntax for installing the VMware Tools on Server Core on ESX 3.0 is:

msiexec.exe /i “<path to VMware Tools.msi>” /qn

while Michael says by way of Mike’s blog:

“For those unfamiliar with Server Core it is a command line only version of Windows Server 2008 (formerly Longhorn). I have been trying to install this on ESX 3.0. On the GUI version of Windows 2008 server, VMWare tools must be installed to get the NIC working. Server Core however is command line only. VMWareTools is a GUI installation so this is not an option for Server Core.

The workaround is to transfer VMWareTools (contained in a file called windows.iso) from your ESX server to a local drive. This can be done using Winscp. Use Virtual Center to mount the windows.iso file as a CDROM drive in the Server Core VM. The driver files are located in \Program Files\VMWare\VMWare Tools\Drivers\VMXNet\w2k of the windows.iso file. The command used to install the drivers is

C:\Windows\System32>pnputil -i -a vmxnet.inf
Microsoft PnP Utility
Processing inf : vmxnet.inf
Successfully installed the driver on a device on the system.
Driver package added successfully.
Published name : oem2.inf

Next check the installation of the driver. Vmxnet should be displayed near the end of the list.

C:\Windows\System32>driverquery
ws2ifsl Winsock IFS driver Kernel 18/04/2007 04:52:40
vmxnet VMware Ethernet Adapte Kernel 22/04/2006 23:13:11

I finally got around to installing Windows Server 2008 Standard today.  I performed a Server Core installation, and was suprised how little interaction I had to have with the installer.  It seemed like I answered three or four questions, went to get a Diet Coke, and when I came back the server was at the logon prompt.

During the install process I had not been prompted to provide an Administrator password like I’d experienced during installations of previous Windows Server operating systems.  I entered Administator as the User Name and hit enter, and I was automagically logged onto the server.

Immediately Windows prompted me to change the Administrator password.  I tried reusing a few of my standard passwords, but they kept getting rejected with the following error:

“Unable to update the password.  The value provided for the new password does not meet the length, complexity, or history requirements of the domain”

I tried to create a new password several more time, but nothing worked.  I finally decided to find out what the default password policy requirements were for Windows 2008.

When this policy setting is enabled, users must create strong passwords to meet the following minimum requirements:

• Passwords cannot contain the user’s account name or parts of the user’s full name that exceed two consecutive characters.
• Passwords must be at least six characters in length.
• Passwords must contain characters from three of the following four categories:

1. English uppercase characters (A through Z).
2. English lowercase characters (a through z).
3. Base 10 digits (0 through 9).
4. Non-alphabetic characters (for example, !, $, #, %).

I thought it was interesting to find the following explanation from the same web page:

“Password must meet complexity requirements -

This policy setting checks all new passwords to ensure that they meet basic requirements for strong passwords. By default, the value for this policy setting in Windows Server 2008 is configured to Disabled, but it is set to Enabled in a Windows Server 2008 domain for both environments described in this guide.”

That was not the behavior I had experienced with my initial install of Windows Server 2008.  This was a core installation and was not a domain member, so why was the policy enabled? 

On another note, when you want to log out of Server Core, simply type logoff