Resetting Forgotten Windows Admin Password

One of the “fun” experiences I have run into in my IT career is the situation where domain trust is broken or the network is not configured, but you absolutely have to get into the box in question. The trouble is the password was set by someone who was in the position before you and there is no documentation. I have come across 2 ways to do this, one of which I consider to the conventional bare metal method and the Hyper-V guest method.

 

Method 1 (Bare Metal Method):

If you have a physical server or a virtual machine that is in another format other than VHD to VHDX use this method. Essentially what we will be doing is booting from the windows disk into a command prompt repair option, backing up and renaming utilman.exe and making a copy of cmd.exe name utilman.exe. This will allow us to reboot to login prompt, press windows + U (which ordinarily brings up utilman.exe) which will launch a command prompt, from where we can reset the administrator password using the net user commands.

The first step is to insert the windows disk, reboot and choose to boot from disk. Once you are on the the screen that present the option to install windows or repair your computer

page1

 

repair-your-computer

Choose the troubleshoot option, and then select to command prompt.

Once you are booted into the command prompt you will need to type the following commands (note D is the normal drive for C: in this prompt, if you primary drive is labeled something other than C you can use diskpart to identify the proper disk)

  • D;
  • cd windowssystem32
  • ren utilman.exe utilman.bkp
  • copy cmd.exe utilman.exe

Close the command prompt, eject the disk and restart. Once you boot to the sign in screen press windows key + U then type the following:

  • net user administrator Password123!

Close the command prompt and login as administrator with the password you just set. Once you have completed this successfully you will want to remove the utilman.exe application and rename utilman.bkp to utilman.exe.

 

 

Method 2 (Mounting VHD Method):

If you are utilizing Hyper-V or another virtualization platform that utilizes VHD or VHDX files you have another option, which is to mound the VHD and perform similar steps to the above. If the VM in question is running shut it down. Once the virtual machine is shut down on the Hyper-V host machine open disk management (diskmgmt.msc) and choose the “action” menu, then select “attach VHD”.

attach vhd

Once you select attach VHD, you’ll need to navigate to the directory where your Hyper-V VHDs are stored (by default this is C:UsersPublicDocumentsHyper-VVirtual Hard Disks). Select the VHD and mount it. Once the VHD is mounted you’ll see it show up as a drive letter, navigate to this drive letter, choose the windowssystem32 directory. You will need to right click on utilman.exe and choose properties, select the security tab, choose advanced security and change ownership to your user account.

utilbak

Once you have taken ownership and applied changes you will be able to add your account on the security tab and grant full control. Once this is applied you will then have the permissions needed to change the filename to utilman.back. Once this is done locate cmd.exe in same directory, right click and copy, then paste and rename to utilman.exe. Unmount the VHD  by opening disk managment (diskmgmt.msc), highlight the disk for the VHD you mounted, then choose “action>all tasks>detach VHD”

detach

Once you have unmounted the VHD you can boot the Hyper-V virtual machine and press ctrl+U at the login prompt to reset the password via command prompt with the following command:

  • net user administrator Passwor123!

Once you are successfully in the server and you need to perform the same cleanup tasks as in method 1. If you run into issues moving utilman.bak to utilman.exe you can try shutting down the VM and re-mounting the VHD to the Hyper-V host and change these options, unmount the VHD and reboot the Hyper-V system.

 

Thank you all for reading and I hope this article is helpful. This article is intended to assist administrators to access systems they have rights to access but lack the password. This article is in no way mean to help or endorse illicit access to systems, please use this information carefully and please act ethically and only use this to access systems you own and/or are authorized to access.

Connecting to a Non-Domain Joined Hyper-V Server From Windows 8.1

While it is best practice to join Hyper-V to a domain, I have run across situations where a standalone Hyper-V server exists in an environment without a domain. This is actually somewhat common in some testing and lab environments. If you are utilizing the free Hyper-V Server Core 2012 R2 or using a server core install of Windows Server 2012 or later as your Hyper-V host OS, you will probably want to connect to it from another server or Windows 8.1 machine. To do this follow the steps below:

Open and elevated command prompt and type dcomcnfg and press enter:

dcomcnfg

Once you are in dcomcnfg you will see a properties window, expand Component Services and Computers node. Then right click on my computer and choose properties.

properties

Under COM Security choose “edit limits” for access permissions

edit limits

Make sure the Local Access and Remote Access are allowed for ANONYMOUS LOGIN, then click OK

access perms

Close the dcomcnfg windows and at the elevated command prompt type cmdkey /add:ip_or_hostname_of_destination_server /user:username_on_destination_server /pass:password_of_destination_server (see example below):cmdkey

Hyper-V Lessons Learned

The past several weeks have been rather hectic and busy. Between work and studying for my Citrix XenServer certification, there’s been a whole lot going on. Virtualization has long been been a passion of mine in the world of IT, and I am certainly getting hands on with lots of virtualization platforms these days (tis one of the many benefits of working for a managed service provider). I have recently been working on a VMware to Hyper-V migration project and have come across a number of interesting gotchas that I figure would be useful to others going through the same process. Some of these lessons range from NTP with Linux, to troubleshooting cluster connectivity, the migration process itself, and some other fun gotchas.

The Conversion Process Itself

Converting virtual machines from VMware to Hyper-V has become and incredibly simple process. First of all on one of your Hyper-V hosts download and install the Microsoft Virtual Machine Convertor (https://www.microsoft.com/en-us/download/details.aspx?id=42497). Once this is downloaded, there is a simple wizard in which you can choose to do a P2V or V2V conversion to either Azure or Hyper-V. From there it is simply a matter of specifying the hostname of the Hyper-V host that will be the destination for the VM, choosing where to store the virtual disk, as well as whether you want fixed disk or dynamically expanding, and VHD or VHDX. At this point the final step is to put in the information from your vCenter server, choose the VM to migrate (powered off beforehand), and follow the wizard to victory. The mechanism by which the conversion takes place is that VMware will export the virtual machine in OVF format, which will then be copied into the Hyper-V workspace and imported into Hyper-V. It’s actually a fairly slick process, however it is time consuming and there are definitely some gotchas. For one the NICs added during the migration process that replace the VMware virtual adapters will be identified as different interfaces on Windows machines so static IPs will have to be re-entered. This is not the case for Linux, as the interfaces file stores the static IP config and there are no issues I have run into during the conversion process with Linux NICs.

Licensing Your Hyper-V Hosts

If you are a primarily a Windows based shop running 2012 R2, I highly recommend setting your Hyper-V hosts up with Datacenter licensing. The Datacenter license covers up to CPU sockets with unlimited VMs on the same hardware. One of the wonderful features of this is that it allows for AVMA or automatic virtual machine activation. Meaning that instead of activating each VM to MS activation servers, you are actually able to activate them to the VM host with Datacenter licensing. Per the following technet article you can activate using an AVMA key (provided in the article) to activate Datacenter, Standard, and Essentials licenses to the host. https://technet.microsoft.com/en-us/library/dn303421.aspx

The activation syntax must be run from an elevated command prompt with the following syntax:

slmgr /ipk <AVMA key>

For this functionality to work, you will also need to ensure that Data Exchange is enabled in the Integration Services for the VM (this is the default behavior)

 

NTP Issues For Linux VMs

I learned the hard way after migrating Linux VMs to Hyper-V that one of the default integration services is time synchronization with the host. I had assumed that NTP would override this behavior but I assumed incorrectly. In VMware when you create a VM if you choose a Linux OS profile it actually turns off this time sync behavior, however in Hyper-V there are not OS specific defaults for hardware, so this feature is on by default all the time for all hosts. If the linux host is running Ubuntu 14 or newer, Debian 8, or Centos/RHEL 7 (really anything that uses systemd) you can run the command timedatectl to see if NTP is running and if it is synchronizing. I found that NTP would not sync if time sync was enabled in the integration services for the VM. To avoid countless annoying Nagios emails about NTP drive I simply chose to disable this functionality in the interest of consistent time and less email.

ntp sync no

 

NTP not synchronized due to time synchronization integration services being enabled.

time sync setting

 

Uncheck the Time Synchronization Options to corret

ntp sync yes

 

NTP synchronized switches to yes after making changes to integration services

Converting Windows VMs with Multiple Disks

One of the more obscure things I have discovered with migrating from Vmware to Hyper-V is that windows VMs with multiple disks import both disks properly and both show in the settings for the VM, however in the OS the additional disks are not enabled by default. To remedy this you simply need to go into disk management (diskmgmt.msc) and right click the disk and choose to bring it online. Once this is complete the disks will show properly.