Microsoft has released their Remote Desktop Load Simulation Tools which have nothing to do with Remote Desktop in the RDP sense.  Instead, the tools are designed for 32-bit and 64-bit server capacity planning and performance/scalability analysis.  According to Microsoft:

In a server-based computing environment, all application execution and data processing occur on the server. Therefore it is extremely interesting to test the scalability and capacity of servers to determine how many client sessions a server can typically support under a variety of different scenarios. One of the most reliable ways to find out the number or users a server can support for a particular scenario is to log on a large number of users on the server simultaneously. The Remote Desktop Load Simulation tools provide the functionality which makes it possible to generate the required user load on the server.

Supported operating systems are:

• Windows Server 2008
• Windows Server 2008 Datacenter
• Windows Server 2008 Datacenter without Hyper-V
• Windows Server 2008 Enterprise
• Windows Server 2008 Enterprise without Hyper-V
• Windows Server 2008 for Itanium-based Systems
• Windows Server 2008 R2
• Windows Server 2008 R2 for Itanium-based Systems
• Windows Server 2008 Service Pack 2
• Windows Server 2008 Standard
• Windows Server 2008 Standard without Hyper-V

(Notice the lack of Windows 2003 support?)

A minimal test environment requires:

1. Target Remote Desktop Server
2. Client Workstations
3. Test Controller Host

Here’s a quick and easy way of checking how long a Windows server or workstation has been up, via the command line.  It pipes the results of Net Statistics Workstation into find.  Run the following from a command prompt:

net statistics workstation | find /i “statistics since”

The results will look like

Statistics since 8/12/2009 11:08 PM

Which shows the machine has been up since 11:08pm on August 12, 2009.

Normally when a Windows workstation or server is locked, you’ll see something similar to the following Windows Security message:  

• User display name, domain and user names (default setting)
• User display name only
• Do not display user information

If this policy is enabled, the name of the last user to successfully log on is not displayed in the Log On to Windows dialog box.  If this policy is disabled, the name of the last user to log on is displayed.

I have an Active Directory domain service account that has permissions to a share on our SAN that will host IIS web site content.  I needed to allow IIS to access the share via the service account.  Here’s how to do it in IIS 7.0 on Windows Server 2008:

1. Open Server Manager > Roles > Web Server (IIS) > Internet Information Services (IIS) Manager > ServerName > Sites > WebSiteName
2. Double click Authentication > Anonymous Authentication > Edit
3. Under Anonymous user identity, select Specific User > Set
4. Enter the user name and password > OK > OK 
5. Restart the web site

Last week I attempted to add a scheduled task to my Windows 2008 server using schtasks.exe. The syntax I used was:

schtasks /create /S server /U DOMAIN\ACCOUNT /P password /SC daily /ST 15:00 /TN BkupIIS /TR c:\scripts\bkupiis.cmd

I received the following message from schtasks.exe:

User credentials are not allowed on the local machine

The task scheduler log file shows the following error:

Task Scheduler failed to start “\BkupIIS” task for user “DOMAIN\ACCOUNT”. Additional Data: Error Value: 2147750687.

The secret to successfully scheduling the task is to use /RU and /RP instead of /U and /P.

The syntax that should be used to create the scheduled task is:

schtasks /create /S server /RU DOMAIN\ACCOUNT /RP password /SC daily /ST 15:00 /TN BkupIIS /TR c:\scripts\bkupiis.cmd

Reference: http://brianagibson.blogspot.com/2008/08/hmc-45-domaincachetask-scheduled-task.html

Microsoft has the Windows System Assessment Tool (Winsat) available for download that can assess a computer’s ability to run Windows Vista.  This tool provides a wealth of information on you hardware’s horsepower, plus it’s scriptable. It’s designed to run under Windows Vista, but can be run under Windows Server 2008 as well.  Here’s how to do it.

I have three Windows 2008 Media servers that I’ve had issues with getting to work behind our F5 BigIP load balancer.  When we took packet traces, HTTP GET requests from the Media Player client have been responded to with 503 Service Unavailable.  

To export a backup copy of your IIS 7.0 configuration on a Windows 2008 Server:

Open Server Manager

Expand Roles – Web Server (IIS) – Internet Information Services (IIS) Manager

Highlight the web server name

From the Management category, double click Shared Configuration

Under Actions, select Export Configuration. Accept or change the default export path of C:\Windows\system32\inetsrv\config\export

Click the Connect As button, and enter administrative credentials. If the server is a domain member, you may need to enter your credentials in the format domain\username or username@domain.com

Enter the encryption keys password twice and press OK

You should now have three files in the C:\Windows\system32\inetsrv\config\export directory: administration.config, applicationHost.config, and configEncKey.key. Save the files in a safe place.

One of my newly deployed Windows 2008 servers was being identified in the McAfee EPO 4.0 admin console as a Windows Vista machine. This was curious to me, since I had created this Windows 2008 server from the same media as it’s predecessors, and had installed all the same versions of software onto it, such as the Common Management Agent 3.6 patch 3, aka FramePkg.exe.

The instructions I received from McAfee Technical support said to copy the sitelist.xml file from the EPO server’s \Program Files\McAfee\ePolicy Orchestrator\DB directory, and paste it into the C:\Documents and Settings\All Users\Application data\McAfee\Common Framework directory on the Windows 2008 server.

First of all, in Windows 2008 C:\Documents and Settings is hidden by default, so in Windows Explorer I had to select Organize – Folder and Search Options – View – Show hidden files and folders in order to even see C:\Documents and Settings.

When I clicked on the C:\Documents and Settings directory, I immediately received the following error, despite being logged in with my domain admin credentials:

C:\Documents and Settings is not accessible. Access is denied.

I noticed the local administators group, which domain admins is a member of, did not have explicit permissions assigned to the directory, so I attempted to assign them, but was once again denied access. I checked ownership, and saw SYSTEM was the owner, so I tried to take ownership of the directory, but was denied. Only after logging in as the local administrator was I able to take ownership, and assign myself rights to the file system.

After much googling I was able to determine the cause of this problem. In Windows Server 2008 (and Windows Vista) the familiar old XP file/directory structure has been replaced. C:\Documents and Settings no longer physically exists, but has been replaced by junction points which are used for backwards compatibility with legacy applications.

These junction points are like shortcuts to the actual data locations, and are not meant to be navigated by the system administrator. The ACLs are set to ““Everyone Deny Read”. Applications must have permissions in order to call out and traverse a specific path.

To make a long story short, instead of placing the sitelist.xml file in the C:\Documents and Settings\All Users\Application data\McAfee\Common Framework directory on the Windows 2008 server, I had to put it in the C:\ProgramData\McAfee\Common Framework directory instead.

I then restarted the McAfee Framework service on the Windows 2008 server. I waited about an hour (not sure if this is necessary, but I was busy), then verified the correct operating system was properly detected on the EPO admin console.

I asked McAfee how to get our custom sitelist.xml file into the new FramePkg.exe file for deployment, and he said that shouldn’t be necessary. If we experience another case like this where the client OS is misidentified for some reason, they will work with us to determine the cause of the problem, rather than have us apply the band-aid fix after the fact.

Figuring out how to edit the order of NIC bindings on a Windows 2008 Server took quite a bit of Googling. It seems that you need to know a secret key combination to be able to view the Advanced tab, where the option to edit the NIC bindings is located.

To edit the network card binding order in Windows Server 2008:

Login to the server with administrative credentials

Click Start > Control Panel > Network and Sharing Center

On the left hand side select Manage network connections

Press Alt+N to display the Advanced menu

Select Advanced Settings. On the Adapters and Bindings tab, highlight your NIC and use the arrows on the right hand side to adjust it’s binding order.

You can also access the Network Connections screen directly by clicking Start > Run , typing ncpa.cpl and pressing Enter