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.
I brought up a snapshot of a Windows Server 2003 R2 guest today and could not login to the domain. After further review I found the server had lost its static TCP/IP settings – both NICs were set to DHCP (they had previously been statically set). When I attempted to add the TCP/IP addresses back to the NICs, I received the following error message:
To delegate the ability to enable and disable user accounts in Active Directory:
I setup our help desk users to be able to restore documents using Microsoft’s Volume Shadow Copy client on remote servers yesterday. Everything worked just fine for me as an administrator, and for users who owned the files, but it didn’t work for the help desk folks. I found out they didn’t have NTFS rights to the files and folders, so I assumed all I had to do was assign them change permissions, and they’d be able to do the restore.
I made the permission change, but when the help desk folks tried to view the contents of the shadow copy snapshots they received “Access Denied” errors. I had them confirm they could UNC to the location where the snapshots were located, and they could create and delete files there.
After much Googling didn’t provide many troubleshooting ideas, I decided to manually create a snapshot of the same volume. I had them test again, and they were able to view the snapshot’s contents and restore files. Underlying cause was the help desk group didn’t have permissions to the original snapshot, so they couldn’t see the files to restore them. Hope this helps someone else out.
The following events were listed in the Windows 2003 event log when one of our second level help desk staff connected to the server console via RDP:
Event 1521 Source Userenv
Windows cannot locate the server copy of your roaming profile and is attempting to log you on with your local profile. Changes to the profile will not be copied to the server when you logoff. Possible causes of this error include network problems or insufficient security rights. If this problem persists, contact your network administrator.
I saved the script as getsid.vbs. Open a command prompt, and execute the script using cscript:
The script will display the SID associated with the user account specified. Delete this from:
to correct the Userenv errors.
Normally when a Windows workstation or server is locked, you’ll see something similar to the following Windows Security message:
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.
Howto fix error when opening Windows Server 2003 Local Security Policy:
The Group Policy security settings that apply to this machine could not be determined. The error returned when trying to retrieve these settings from the local security policy database (%windir%\security\database\secedit.sdb) was: The parameter is incorrect.
All local security settings will be displayed, but no indication will be given as to whether or not a given security setting is defined by Group Policy.
Any local security setting modified through this User Interface may subsequently be overriden by domain-level policies.
Windows cannot read template information.
Many documents suggest that renaming the %windir%\security\database\secedit.sdb file and rebooting the server will resolve this issue by recreating the security database. Unfortunately, this procedure never resulted in the secedit.sdb database file being re-created, even after a server reboot.
I also tried importing a new secedit.sdb database, but that failed with the following error:
An extended error has occurred. Import failed.
After much Googling I came across MS KB932461 You cannot determine Group Policy security settings on a Windows Server 2003, Enterprise Edition-based computer. Even though the OS of the offending servers is Windows Server 2003 R2 Standard (not Enterprise) the fix described in the KB document fixed this issue.
The cause of the problem is explained by the KB as
“This problem occurs if specific Group Policy security settings are changed from their default settings. These security settings specify the minimum required security setting of server-side and client-side network connections for programs that use the NTLM security support provider (SSP).”
The solution was to edit the registry key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Set the values of NtlmMinServerSec and NtlmMinClientSec to 0 (zero)
Wait about 15-30 minutes for the change to take effect and you should be able to view the Local Security Policy once again!
If you’re curious what these keys do, NtlmMinServerSec specifies the minimum required security setting of server-side network connections for applications using the NTLM security support provider (SSP).
NtlmMinClientSec specifies the minimum required security setting of client-side network connections for applications using the NTLM security support provider (SSP).
In my case both of these settings had previous values of 0×20080030 which enforces message integrity, confidentiality, use of NTLMv2 and 128-bit encryption.
It seemed like a simple enough task – Install Windows Server 2003 R2 Standard x64 on a Dell PowerEdge 2950 x64 server that is about a year old. The server contains three 500GB SATA drives plugged into an internal PERC 5/i SAS RAID controller. The server also lacked an internal floppy drive, and there was no available slot to add one.
The problem started out being that the Windows installer didn’t see the system’s hard drives during the setup process.
This is a common problem, especially with newer RAID controllers. Normally you can load the manufacturer’s drivers during the Windows setup by pressing F6 – S to specify mass storage drivers once the blue installation screen appears. I had to search long and hard to find the Dell Windows Server 2003 64-bit drivers for the PERC 5/i because for some reason when you enter your server’s system tag and search for SAS RAID drivers only the 32-bit version is available for download.
I added the 64-bit RAID controller drivers to my floppy disk, but when I pressed F6 – S to specify new drivers, Windows did not detect the presence of my USB floppy drive, which I had plugged into the USB ports on the front of the server. I rebooted the server with the drive into plugged into a USB port on the back of the server, but had the same result.
Next I tried copying the drivers to my USB flash drive, which I tried in the ports on both the front and the back of the server, and the installation program failed to see that drive as well.
I searched support.dell.com for a solution, and of course I didn’t find one. I did find a link to the Dell USB Key F6 Driver Utility, which allows you to copy mass storage drivers to a USB flash drive and have them recognized by Windows during an installation. This sounded like exactly what I needed.
I downloaded the USB utility, and when I executed it I was informed this program would format my flash drive, which would obviously delete everything I had saved to it. I went and found a different drive that I didn’t care if it’s contents were deleted, and ran the program. It took about three seconds to run, and I went back to my server and ran the Windows 2003 setup again – and once again the installer did not recognize my flash drive. I tried to view the contents of the flash drive on a Windows XP computer, but I was informed the flash drive was not formatted. Obviously, I had done something wrong.
After reading the USB utility’s readme file, I found I had missed some very important details. Information from the USB utility’s readme file are highlighted in red.
1. One of the files in the driver package is TXTSETUP.OEM. Edit
TXTSETUP.OEM with NOTEPAD (or a text editor of your choice). In the
[Defaults] section locate the line that starts with “scsi = “. The
value on the right hand side of the equals sign must represent the
Windows Server 2003 mass storage driver.
The values permitted on the right hand side of the equals sign are defined in the [scsi] section.
If the value on the right hand side represents the Windows 2000 mass storage driver, it must be updated.
The following table lists the drivers that are available for download for 9G servers. The table
indicates whether the TXTSETUP.OEM file needs to be updated at the time this document was written (Oct 24, 2006).
Dell SAS 5/E Adapter No change needed
Dell SAS 5/i Integrated No change needed
Dell PERC 5/E Adapter Must be changed
Dell PERC 5/i Integrated Must be changed
Adaptec 39320A Controller No change needed
LSI Logic CERC ATA 100 Must be changed
LSI Logic PERC 4/DC Must be changed
LSI Logic PERC 4/Di Must be changed
LSI Logic PERC 4/SC Must be changed
LSI Logic PERC 4e/DC Must be changed
LSI Logic PERC 4e/Di Must be changed
LSI Logic PERC 4e/Si Must be changed
LSI Logic PERC3/DC Must be changed
LSI Logic PERC3/DCL Must be changed
LSI Logic PERC3/QC Must be changed
LSI Logic PERC3/SC Must be changed
I had the Dell PERC 5/i Integrated controller, so I had to modify TXTSETUP.OEM for the flash utility to operate properly.In the TXTSETUP.OEM file’s [Defaults] section I had to change the line that starts with “scsi = PERC_32″ to “scsi = PERCsas”, where percsas.sys was the name of my 64-bit RAID controller driver.
2. Local administrator rights are required to create a bootable flash
drive from the USBKeyPrepF6 Utility. Flash drives up to 16 GB in size
are supported. After the USB key is prepared by the USBKeyPrepF6
Utility, the USB key’s contents are not accessible from Windows. If
the USB key is plugged into a system running the Windows operating
system, Windows may report that the USB key has an unrecognized file
system or that it is uninitialized. However the USB key’s contents may
be accessed from DOS, by using floppy emulation.
That pretty much explained why I couldn’t read the drive’s contents from my XP machine.
3. Windows 2003 installation instructions:
Place the USB key into a USB port of the system on which you are
installing Windows Server 2003. Insert the Windows CD into the CD
drive. Reboot the system. During boot press F2 to enter the BIOS setup
utility.
If your system has a Dell Remote Access Controller 5 (DRAC 5) then also press Ctrl-E, when prompted, to enter Remote Access Setup, also known as the Remote Access Configuration Utility.
My server has a Dell Remote Access Controller 5, so I had to press Ctrl-E to access the DRAC configuration.
Within the Remote Access Configuration Utility, select Virtual Media
Configuration. Select Virtual Media and select Detached. Select
Virtual Flash and select Disabled. Save these changes and exit the
Remote Access Configuration Utility.
I changed the Virtual Flash setting from Attached to Detached. Virtual Flash was already disabled, so I saved the changes and exited the Remote Access Configuration Utility.
Within the BIOS setup utility, select USB Flash Drive Emulation Type.
On this menu select Floppy emulation for the USB key. Save this change
and exit the BIOS setup utility.
I entered the server’s BIOS and changed Drive Emulation Type from Auto to Floppy Emulation. I saved my settings and exited the BIOS setup utility and rebooted with my flash drive inserted into one of the front USB ports. I booted from the Windows Server 2003 CD, pressed F6 – S to specify an additional mass storage driver, and the setup program found the PERC drivers on the USB drive! Finally, my installation could progress!
My elation was short lived, though. When I got to the part of the installation where I could specify the boot partition size, the maximum size Windows would allow me to use was 957 MB (yes, that’s megabytes, not gigabytes).
I rebooted again and pressed Ctrl-R to enter the PERC controller configuration utility and confirmed my RAID 5 array was indeed 950 GB (as in gigabytes). Just to make sure nothing was corrupted on my array I began the array verification process and left the site for the evening. Of course I would find out later the array was just fine.
The next day I emailed Dell tech support and explained how the Windows installation program would only allow me to create a partition of 957 MB. The tech who responded to me suggested that I download the Dell Installation and Server Management Disk and boot from the .iso it creates to configure the RAID array and perform the Windows installation.
I downloaded and burned the .iso image, then booted the server from the CD. I chose to install a Windows 2003 x64 server, filled in all the field the Server Assistant required, and was finally able to successfully install Windows onto a partition much greater than 957 MB in size!
In hindsight I may have been able to just slipstream the controller drivers along with Service Pack 2 into the Windows 2003 x64 Server source files, but I’m thinking that probably would have only seen the drive array as 957 MB in size as well.
recent updates