Blog: Windows 2003 Server

I needed to troubleshoot a printing problem on one of our test servers to determine if the problem was caused by software updates that I did or if it was pre-existing.  I had a snapshot of the server prior to any of my work, so I wanted to create a new snapshot so I could roll back, test, and roll forward again after the test. 

For some reason, when I rolled back the server to the earlier snapshot, I could not login with domain credentials.  The event log had recorded: “Windows cannot determine the user or computer name. (Access is denied. ). Group Policy processing aborted.”  Typically when this is seen, the computer account is messed up and you can unjoin and rejoin the computer to the domain to reestablish the account. 

After my testing was finished, I decided to go ahead jump forward to the recent backup before I rolled back.  I received the same message and could not login to the domain.  I went into the system properties and changed the PC from domain to workgroup named “workgroup”.  After this, the server asked me to reboot to finish applying the changes.  When I rebooted the server, I noticed all the software that was pushed out by group policy was now being uninstalled.  I went ahead and kept going and rejoined the server to the domain (10 – 15 minutes later to allow for AD replication).  The server asked me to reboot again after joining the domain, and it proceeded to install the group policy software that had just been removed.  Even though I could now login to the domain, there were a few things that still didn’t work quite right because of this, such as programs that GP should have been removed from a previous MW were still there. [more]

I reverted back to my snapshot again, changed the server from domain to workgroup, and let it sit for (10-15 minutes) while declining to reboot.  I joined the server back to the domain and then elected to reboot the server.  This successfully kept all of the previous software installed by GP and uninstalled the software that was specified by the previous MW GP modifications.  So to save yourself problems in the future when fixing computer account association, don’t reboot after unjoining the domain, but DO reboot after rejoining.

When building a terminal server, don’t forget to uninstall IE Enhanced Security BEFORE you install terminal services on a Windows 2003 Server, especially if you plan to sysprep the server and image it. For some reason, if you don’t do this, certain keys are left behind in the registry and in the default profile user hive (ntuser.dat file) that cause issues. IEES is uninstalled, but new user profiles created on that server still have remnants and do not function as expected. Users may get the IEES pop-ups when visiting any site that is not in their trusted sites list and it seems to affect JavaScript execution privileges as well. Here is the Microsoft article that addresses this issue (http://support.microsoft.com/kb/)933991). The workaround if this has happened is to follow Method 4 and then rebuild the affected profiles. If Method 3 is followed, it doesn’t seem be a complete fix from our experience.

When installing the first Windows 2003 domain controller in a Windows 2000 Active Directory domain, you must first run ADPrep on the Windows 2000 domain controller.  ADPrep is provided on the Windows 2003 media.  BUT, Windows 2003 R2 requires a different version of ADPrep.  It can be found on Disc2 of the media set; the ADPrep on Disc1 will not allow you to install a Windows 2003 R2 domain controller.

1. Basic disks use the original MS-DOS-style master boot record (MBR) partition tables to store primary and logical disk partitioning information. Dynamic disks use a private region of the disk to maintain a Logical Disk Manager (LDM) database. The LDM database contains volume types, offsets, memberships, and drive letters of each volume. The LDM database is also replicated, so each dynamic disk knows about every other dynamic disk configuration. Performing FIXBOOT and FIXMBR in the recovery console of a system configured with Dynamic disks has no affect on the health of the LDM.
2. Never break a healthy system disk or boot dynamic mirrored volume and expect the mirrored drive to replace the original primary drive if it fails. The manually broken mirrored drive is assigned the next available drive letter, and this is updated to the permanent record in the LDM database. This means that regardless of what position that drive takes in the boot process, it is assigned the new (and incorrect) drive letter, so the operating system cannot function correctly.
3. If you want to replace a failed disk in a dynamic disk-based volume, shut the system down just like normal. Do not break the mirror or change the volume properties in preparation for the removal. Once the system is down, replace the bad drive and reboot. It may be necessary to place the secondary drive at the same SCSI ID as the primary before reboot if you are replacing the primary drive in a mirrored set.

MANY other helpful hints are available at http://support.microsoft.com/kb/816307.

While working on a task to upgrade the hard drives on a Windows 2002 SBS machine. I installed Acronis in order to create an image of the C & D drive then recover it to the new larger hard drive. I recovered the image to the new drives and finished getting everything back online.

I decided to uninstall Acronis which showed to uninstall just fine using it’s uninstall. After backup ran that night it had Volume Shadow Copy errors. I checked and found that the Microsoft VSS writers where not accessible. I ran “VSSadmin / list writers” which showed there was no writers available. After researching I found that others who uninstalled Acronis 9.1 had the same issue. I could not find a solution that worked for anyone. I found an article (linked to below) that has a list of DLL’s that Micrisoft Premier Support recommends to reregister. I reregistered the DLL's and after a reboot there were still no VSS writers available.  [more]

I then decided to run System File Checker which is built into Windows XP and Server 2003. I used “sfc.exe /scannow” and let it run. After which I reregistered the DLL’s like before. This time when I ran “VSSadmin /list writers” all the writers were listed. I went back to Backup Exec and was able to select “Shadow?Copy?Components” and “System State”, which I could not before.

Link to information about SFC.exe   -   http://support.microsoft.com/kb/310747
Link to list of DLL’s to reregister  -   http://backupassist.com/phpBB3/viewtopic.php?t=28

When running dcdiag.exe from the Windows Support Tools against a x64 domain controller, make sure you are running the x64 version of dcdiag.exe. If you try to run the x86 version of dcdiag remotely against an x64 domain controller, the tool may report errors when there really isn’t anything wrong. In my case, I could not get the x64 domain controller to pass the Kerberos and DNS tests when running dcdiag.exe against it from a remote x86 server; however, when I installed the x64 version of the support tools locally on the domain controller, everything passed without error.

We recently experienced a very strange issue with Exchange 2007 CCR. We had the MNS cluster w/file share witness running and the CCR mailbox servers were all replicating nicely. However, at very random intervals, replication would just stop happening from the primary to the secondary node. During these times, I could not RDP to the server, but I could ping it and log on locally so it wasn’t frozen in the literal sense. File share FROM the machine worked, but file share TO the machine didn’t. Rebooting the passive node would fix the issue. After about 4 days of troubleshooting (2 of those with Microsoft), I think the mystery may be solved. It goes something like this… [more]

In Windows Server 2003 SP2, Microsoft introduced a new set of features collectively known as “Scalable Networking Pack”. This package of features includes a TCP Chimney Offload (TOE) feature, a Receive-side Scaling feature, and a NetDMA feature. Basically, this allows network card driver developers to implement offload features on the NICs so that the a certain portion of the network stack can be offloaded to the NIC card processor. It is a great idea, but unfortunately, the driver manufacturers haven’t implemented the technology correctly. Partly because the feature set is buggy and partly because the NIC drivers are not thoroughly tested. One of the worst instances of this situation is with Broadcom NICs (yes both HP and Dell use Broadcom chipsets). Generally, what happens is that the server starts exhibiting very strange RCP-related issues. RDP may not work, management via WMI may be broken, event log viewing will be VERY slow, etc. In my case, Exchange 2007 replication stopped working. So, if you notice these types of behaviors or experience any type of issue where RCP just doesn’t seem to be working correctly, set the following registry keys to 0.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPChimney
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableRSS
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableTCPA

Then reboot the server. This basically turns off any offloading features at the OS level.

One of our customers is running Symantec Mail Security for Microsoft Exchange 5.0.  We were having trouble with the service hanging up in a "Starting" state when the server started up.  [more]See below the picture below.

I wanted to delay this service from starting up until the server boot process was further along.  Using the command “sc query”, I was able to see the Service Name: SMSMSE that matched up with the Display name in the services list.

Since the service was hung up, I could not set the service startup type to disabled or manual.  In the service properties, Log On tab, click the disable button to disable the service from starting up for the hardware profile, and reboot the server.  After the server has rebooted, make sure to go back and “Enable” the hardware profile.

While the server was booting up, I connected to the services list of the server from another PC.  This way, I could see which services were starting up towards the end of booting.  One of the last services to start was “Microsoft Exchange Information Store”.  Knowing that, I needed to find the Service Name to match the Display Name.  Using “sc query” again, I found the service name to be MSExchangeIS.

In order to get the SMSMSE service to startup AFTER the MSExchangeIS service started, you have to specify that SMSMSE depends on MSExchangeIS to be started before it can start.  To do this, open regedt32.  Regedit will not work in this case because we have to edit a REG_MULTI_SZ key.  Go to the following location in the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Service name>.   The key to edit or add is “DependOnService”.  In this case, I added “MSExchangeIS” to this list so the service would not try to start until this service was started.

After this change was made, the SMSMSE service was delayed long enough for it to be able to startup automatically.

In the past, we had removed the Firewall Client Management Tool (fwcmgmt.exe) from the Startup folder for All Users during Terminal Server setup. This was done to prevent the icon from showing up in the system tray for all users.

It appears that this tool must be running in order for firewall configurations to be pushed out from ISA. Recently we configured the firewall client to disable web proxy in order to force all applications (IE, etc) to use the firewall client. However, these settings were not pushed out for users because the Firewall Client Management Tool was not running. [more]

Adding this tool back to the All users Startup folder enables this process to run for all users. In addition, you can modified an ini file (Documents and Settings\All Users\Application Data\Microsoft\Firewall Client 2004\management.ini) on a server so that the system tray icon will be hidden for all users.