It’s been a long time but today I tried logging into a PC and was greeted with the familiar “The trust relationship between this workstation and the primary domain failed”. Fortunately I was able to log in with the local administrator account and fix the domain trust issue with Powershell. This command is much easier and faster than the old way of unjoining/rejoining the domain and doesn’t require a reboot. Open Powershell as local admin and type:
Reset-ComputerMachinePassword -Server DomainController -Credential Domain\AdminAccount
Enter your admin credentials in the popup window and you should be all set.
vlmcsd is an open source KMS emulator that can run on a variety of CPU architectures and operating systems. You can find it officially on the My Digital Life forum (registration required) although at least one other person has mirrored it on GitHub. I’ve been running it for the past few months on my Skull Canyon NUC running Ubuntu 18.04; below are instructions to get it running as a service.
The easiest way to download is through Github. I also renamed the binary to just
vlmcsd to make it simpler and copied it to
mv vlmcsd-x64-musl-static vlmcsd
sudo cp vlmcsd /usr/local/bin
sudo chmod +x /usr/local/bin/vlmcsd
Make a user to run
vlmcsd as a service and give the user permissions on the binary:
sudo useradd -s /usr/sbin/nologin -r -M vlmcsd
sudo chown vlmcsd:vlmcsd /usr/local/bin/vlmcsd
sudo vi /lib/systemd/system/vlmcsd.service
Give it the following contents:
Description=vlmcsd KMS emulator service
ExecStart=/usr/local/bin/vlmcsd -L #YOUR_IP_ADDRESS_HERE -l /var/log/vlmcsd/vlmcsd.log
Make a folder under
/var/log for logging and give the vlmcsd user permissions:
sudo mkdir /var/log/vlmcsd
sudo chown vlmcsd:vlmcsd /var/log/vlmcsd
Now you just need to enable and start the service:
sudo systemctl enable vlmcsd
sudo systemctl start vlmcsd
Check the status of the service:
sudo systemctl status vlmcsd
If all goes well, you should see output similar to below:
● vlmcsd.service - vlmcsd KMS emulator service
Loaded: loaded (/lib/systemd/system/vlmcsd.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2019-06-30 23:46:42 PDT; 22h ago
Process: 3235 ExecStart=/usr/local/bin/vlmcsd -L 192.168.1.22 -l /var/log/vlmcsd/vlmcsd.log (code=exited, status=0/SUCCESS)
Main PID: 3240 (vlmcsd)
Tasks: 1 (limit: 2319)
└─3240 /usr/local/bin/vlmcsd -L 192.168.1.22 -l /var/log/vlmcsd/vlmcsd.log
To activate a product like Office 2016 against this KMS emulator, you can use the
ospp.vbs script located in your Office installation folder:
# Change to Office installation directory
cd "C:\Program Files (x86)\Microsoft Office\Office16"
# Set the KMS server to be used for activation
cscript ospp.vbs /sethst:#YOUR_IP_ADDRESS_HERE
# Activate Office against the set server
cscript ospp.vbs /act
Some time after building my emulation PC I noticed the “Most used” list in the Start Menu only ever displayed the default MS apps, even after a clean install of Win10. The most common programs launched on that PC are RetroArch, Launchbox and Steam yet none of them appeared in the list.
Searching on Google mostly yielded results of people complaining about it but no real solutions. Eventually I found a solution at the bottom of this thread – basically boils down to making another language the default in Windows and then switching back to your original language setting. Somehow this resets the list and allows it to update correctly.
- Go to Start Menu > Settings > Time & Language > Region & Language
- Click on Add a language > search and add another language (preferably one you can actually read…) installing the default options.
- Make the new language your default and reboot.
- After rebooting, go back to Start Menu > Settings > Time & Language as before and change your default language back to the original and remove the language you added in step 2.
After performing these steps, the “Most used” list should be populated with new apps after a few launches. I originally did this fix on Windows 10 1803 and my “Most used” list still accurately reflects app usage even after upgrading to 1809. Hopefully this bug doesn’t exist anymore but it’s worth giving the above steps a try if you stumble on this post while using a future build of Win10.
Recently I needed to image several laptops; it worked fine the first day but the next day imaging was unsuccessful with every laptop showing the “Failed to Run Task Sequence” message with error code 0x8007000F. This was a new SCCM environment for me and I decided to google the error code to see what I could find. Funny enough I found a temp solution on a blog that uses the same base theme as this site (WordPress Twenty Fourteen). Error code 0x8007000F means the imaging environment is unable to find/format the disk properly before applying the image.
select disk 0
create partition efi size=300
format quick fs=fat32
create partition msr size=128
create partition primary
format quick fs=ntfs
Using the above commands to manually format/partition the drive in each laptop helped me get the imaging working; the true solution was for the SCCM admin to rollback the image to a previous version as these commands shouldn’t be necessary.
I recently did a clean install of Windows 10 on my primary workstation. After installing most of my apps again, I noticed that the search function in the Start Menu was only finding some of the applications I had installed. Instead of clicking on shortcuts to launch applications, I’ve grown accustomed to using Windows Key to search for the app I want to launch; a habit that stems from my time spent on a Mac using Command-Space bar to search for and launch applications. Not being able to find every app that is installed was very annoying; also puzzling since I had just done a clean install of Windows. In googling this problem, I found different answers regarding rebuilding the index cache, checking the Windows Search service, reinstalling Cortana, or deleting some registry key. I didn’t find a solution until I stumbled onto this Reddit thread – apparently if you disable background apps under Settings > Privacy > Background apps it prevents Windows Search from working correctly.
Funny enough, this answer is in the first result from my Google search above but I didn’t see it until I wrote this post; I just never bothered to scroll down far enough.
I recently tried to set up Windows Deployment Services (WDS) on Server 2012 R2 in my home lab environment; WDS has been around since Windows 2003 and sadly I’ve never tried using it until now. It allows you to deploy Windows operating systems quickly by allowing workstations to PXE boot from a WDS server; you no longer need a DVD or USB stick with Windows on it in order to image a desktop or laptop. You can simply boot a machine via PXE and select the appropriate image to install; you can also include driver packages to be installed automatically or build your own custom images by capturing a sysprepped machine.
Installing Windows Deployment Services is straight forward; if you’ve added a Server Role before like DNS or DHCP then you’ll be familiar with the process. You can read more about it here. I already had a 2012 R2 VM running as a Domain Controller; I added the WDS role first and then the DHCP role as I needed to provide DHCP Options 60, 66 and 67. I initially only added options 66 and 67 for the server IP and boot path; I didn’t immediately notice a way to specify Option 60 and tried PXE booting my notebook anyway. The PXE boot process failed (connection timeout) and I noticed the Event Log on the WDS Server had one error concerning Event ID 772:
After looking up Event ID 772, I found the issue was due to having WDS and DHCP running on the same machine; it seems they both listen on some of the same ports which why the error log mentions “some other application is already using the port.” I fixed this by enabling the following options in the WDS Server properties:
These options can also be enabled by command line:
wdsutil /Set-Server /UseDHCPPorts:No /DHCPOption60:Yes
After enabling those options I was able to successfully boot from an install image I had added. Next I tried creating a custom install image based the Windows install that was already on my notebook. I created a capture image by following the TechNet instructions but it gave an error when I tried to boot from it; the error was a “Windows failed to start” message similar to this one:
I don’t know how but someone in this thread figured out that mounting and unmounting the capture image resolves the issue. I issued the following commands to fix my capture image:
C:\Users\Administrator>dism /mount-wim /wimfile:"D:\RemoteInstall\Images\Windows
7 Pro SP1 x64 Capture\capture.wim" /mountdir:D:\Stuff /index:1
Deployment Image Servicing and Management tool
The operation completed successfully.
C:\Users\Administrator>dism /unmount-wim /mountdir:D:\Stuff /commit
Deployment Image Servicing and Management tool
Image File : D:\RemoteInstall\Images\Windows 7 Pro SP1 x64 Capture\capture.wim
Image Index : 1
The operation completed successfully.
Now I could boot my capture image and after fixing my issue with sysprep, I was able to capture and upload the Windows install on the notebook (complete with applications and drivers) to the WDS Server. I installed the image I captured but ran into an error message as Windows was booting: “Windows could not finish configuring the system”.
After installing a custom image on a notebook via Windows Deployment Services, I received the following error message as soon as the machine started:
I found this thread and decided the first solution was a bit more complicated than what I wanted to do at the time; I was about give up and chalk up the error message to a compatibility issue with some software I had installed but I decided it would be best to figure it out and know for sure. Then I found this blog post which coincidentally references the same TechNet thread I was looking at earlier. The author of the blog writes that the correct solution was booting into Safe Mode first, waiting for the error and then rebooting again solved the issue; I tried this on my notebook and it worked. It wasn’t until I started writing this post that I noticed the person who posted the first solution in the TechNet thread was using ESET Antivirus; I also have ESET on my notebook which is probably what caused the issue in the first place.
I was trying run Sysprep on a spare notebook in order to test image capture via Windows Deployment Services when I received a rather unhelpful error message: “A fatal error has occurred while trying to sysprep the machine.” After looking into the error log I found something more useful and ran a search for drmv2clt.dll sysprep and found the following thread:
The OP of the thread figured out that the issue was due to the “Windows Media Player Network Sharing Service” – as soon as I disabled the service I was able to run sysprep successfully. It is interesting how this thread dates back to 2009 and how another poster writes that this issue was fixed in Windows 7 RTM; I was running sysprep on a notebook running Windows 7 SP1 with all current updates.