Determining when a local Windows account password was last changed

Our corporate policy requires us to change Windows server local Administrator passwords on a regular basis.  We have a script that accomplishes this, and after the change we do a QA check to validate the passwords were actually changed.

To determine when a local account password was last set (administrator, in this example) , run the following command:

net user Administrator | find /i “Password last set”

The result looks like:

Password last set            7/8/2010 11:14 AM

Tested on Windows 2000, Windows XP, Windows 2003, and Windows 2008.

Note: Just typing net user accountname will provide lots of good details about the user account.

C:\>net user administrator
User name                    Administrator
Full Name
Comment                      Built-in account for administering the computer/domain
User’s comment
Country code                 000 (System Default)
Account active               Yes
Account expires              Never

Password last set            7/8/2010 11:14 AM
Password expires             Never
Password changeable          7/9/2010 11:14 AM
Password required            Yes
User may change password     Yes

Workstations allowed         All
Logon script
User profile
Home directory
Last logon                   8/3/2010 5:42 PM

Logon hours allowed          All

Local Group Memberships      *Administrators
Global Group memberships     *None
The command completed successfully.

Microsoft releases load simulation tools for desktops

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

Find Windows system uptime from the command line

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.

Fix: The IP address you have entered for this network adapter is already assigned to another adapter that is hidden from the Network Connections folder because it is not physically in the computer

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:

“The IP address you have entered for this network adapter is already assigned to another adapter “Fast Ethernet Adapter #2”. “Fast Ethernet Adapter #2″ is hidden from the Network Connections folder because it is not physically in the computer. If the same address is assigned to both adapters and they both become active, only one of them will use this address. This may result in incorrect system configuration. Do you want to enter a different IP address for this adapter in the list of IP addresses in the Advanced dialog box?”
Solutions – KB825826 outlines several potential fixes.  I ended up using Method #6 to remove the hidden network adapter.  To uninstall the ghosted network adapter from the registry, complete these steps:
  1. Click Start, click Run, type cmd.exe, and then press ENTER.
  2. Type set devmgr_show_nonpresent_devices=1, and then press ENTER.
  3. Type Start DEVMGMT.MSC, and then press ENTER.
  4. Click View, and then click Show Hidden Devices.
  5. Expand the Network adapters tree.
  6. Right-click the dimmed network adapter, and then click Uninstall.
Next I configured the static IP on the NIC, and regained network connectivity.  A reboot was required in my case, only because services dependant on domain availability did not automatically startup.

Howto: Reset a lost VMware guest password

So you’ve forgotten your VMware Linux or Windows guest password?  Here’s how to reset it.  These instructions focus on resetting the password through the Virtual Infrastructure Client, but there’s no reason you couldn’t do it using VMware Workstation or VMware Server.  

1. Grab a Kon-Boot .iso image.
2. In the Virtual Infrastructure client, configure the problematic guest’s Virtual CDROM for the Kon-boot ISO image.
3. Boot the problem guest server.  At the VMware BIOS screen, press the ESC key to bring up the boot menu.  Select to boot from CD-ROM.
4. When the Kon-Boot splash screen appears, press Enter to boot Windows.
5. At the Windows login screen, enter administrator as the user name, with any password you’d like.  Note:  This password is not persistent!  You must set the administrator password manually! Once the password is set, reboot the server and you will be able to login with the newly set credentials.
If you are trying to reset the password in Linux, the steps are the same, but instead of logging into Windows and resetting the adminstrator password, login to Linux and reset the root password.

Howto: Delegate the enable/disable accounts permission in Active Directory

To delegate the ability to enable and disable user accounts in Active Directory:

  1. Launch Active Directory Users and Computers with adminsitrative credentials
  2. Right click on the OU where you want to delegate the ability to enable and disable user accounts
  3. Select the Active Directory security group that you want to delegate the ability to and press Next
  4. Select Create Custom Task to Delegate and press Next
  5. Under Delegate Control Of select the Only the following objects in the folder radio button
  6. Select the User objects check box and press Next
  7. Under Show these permissions uncheck General and select Property-specific
  8. Select the Read userAccountControl and Write userAccountControl check boxes and press Next and Finish
You’ve now delegated the ability to enable and disable AD user accounts to a security group.
Additional References

Access is denied when attempting to view or restore Volume Shadow Copy contents

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.