Windows 10 has already had one big “upgrade” released, version 1511 in November 2015. Another one is coming soon in Summer 2016. After you run these updates to Windows 10, you can no longer use the Sysprep tool because it considers these to be full OS upgrades. The error you get is “Sysprep was not able to validate your windows installation.” Fortunately a trick from Windows 7 and 8 days still works to get around this limitation. I found that you only have to do the first 2 steps from the source, so I only reproduced those here.
Below is the method that I found to work perfectly.
Remove this KEY from the Registry:
Remove this REG_DWORD from the Registry:
After your operating system is activated re-run SysPrep and it will work!
It used to be that when you bought a computer from the store, it would have a sticker on the side with your Windows product key written on it. This was so in case you had to reinstall the computer, you could reenter the product key easily. Recently they have changed to embedding the key in the BIOS, so Windows setup can read it without you having to type it. This is better for many situations but not all. One place this doesn’t help you is if you’re installing Windows 10 as a free upgrade on one of these systems, and for some reason the activation doesn’t go right. Your Windows 10 will not be activated, and if you only had the old Windows 8 product key available, you could enter it and be in good shape.
This page details several ways to extract the hidden key from the BIOS. I had to do this today, and I was able to get the key and activate. And write the key down for next time! The software I used was RWEverything, available at rweverything.com. Once I opened that, I went to the ACPI tab, then the MSDM tab. and right there was the product key in plain text.
Sometimes if you move a Windows motherboard to a new motherboard/CPU, it all works perfectly. Sometimes you get a BSoD at startup and a reboot loop. The difference seems to come down to differences in chipsets between the two computers. In Windows XP I used to run what was called a “repair install” to get past this. In Vista and 7 they removed that option so I had no idea what to do to get past it.
I found a method for getting past this, and in my testing of one computer it seems to work. I found it on this page. It involves booting with a CD, going to the Command Prompt option, and using the DISM command to preload all drivers from the motherboard CD into Windows.
dism /image:c:\ /add-driver /Driver:X:\ /recurse
Change drive letters to match, of course.
I had an issue where Outlook 2007 and above, with an Exchange 2010 server, would constantly ask for a password. It was a problem with AutoDiscovery authentication. The solution was found here:
A couple of Windows 8 tips that I needed to find this week and may need again.
We had an extended power outage the other day, where the battery backup on the servers ran out and everything shut down. That’s not great, because you always want to have at least one DC up and running at all times. But there were many other problems after the power outage, and I finally tracked them down. DFSR, SYSVOL, and NETLOGON were not running correctly on the 2012 servers, causing them not to be domain controllers anymore, so the only DC was the old 2008 R2 one that was on the road to being decommissioned. After much researching, I found some links that explained how to get it all working again.
I was researching how to change the Subnet Mask of a DHCP scope on a Windows 2008 server. It turns out you can’t change the subnet without deleting the scope and recreating it. If there are a lot of customizations to the scope, though, like reservations and scope options, it’s no easy task to delete and recreate the scope. Luckily I found one page that explains how to export the scope to a text file, make changes, and then reimport it. The whole process takes only a couple of minutes, and you end up with a deleted and rebuilt scope that has all your customizations intact.
Use the below command to export the scope configuration
C:\>netsh dhcp server \\”Server name” scope “scope subnet” dump>c:\dhcp.txt
C:\>netsh dhcp server \\Test01 scope 192.168.1.0 dump>c:\dhcp.txt
That creates a text file you can edit to change the Subnet, and whatever else you want changed. Then you have to delete the scope from the DHCP manager, and reimport the text file to create a new scope with the settings you specified.
C:\>netsh exec c:\dhcp.txt
I did it and it was exactly as easy as it sounds. After renewing my lease, the clients had the new DHCP scope. In all, it was a painless operation.
When you are transferring your Outlook installation to a new computer, it is simple to move your mailbox folders. You just need to find and copy the PST file and move it to the new computer. But that is only half the battle. That moves your folders, but it does not move your account settings, all that info about your POP servers and logins. Recreating that can be a pain sometimes, and time consuming.
There is a way to copy all of that info in one go. It’s not quite as simple as moving a PST, but it’s not bad if you know what you’re doing. All of that info is stored in the registry, under the key HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows Messaging Subsystem\Profiles\Outlook. All you have to do is export that key from the old computer, and import it on the new computer, and all of your account settings will copy over.
Starting with Outlook 2013, the registry key has changed to HKEY_CURRENT_USER\Software\Microsoft\Office\<version>\Outlook\Profiles.
I had an interesting and obscure problem today with a solution that was buried deep in the registry. Which is what this blog is all about! IE8 on Windows XP would go to www.google.com, but it would not go to google.com. I just got a message instead.
Microsoft Internet Explorer Cannot find ‘google.com’. Make sure the path or internet address is correct.
It was happening with other sites too; it would go to them if I included www, but would not go to them without. I knew there had to be some setting or registry entry that was screwed up, but I didn’t know where to look.
Finally I found the solution on the Maxthon support forums. It was a registry entry indeed. Under this registry key:
There are two subkeys, DefaultPrefix and Prefixes. In each of these is a (Default) value that should be set to http://. On the computer that was not working today, one of them was (value not set). I changed it, and it started working right away.
I had a problem with a computer where after cleaning off a virus there was no internet access, and no network connectivity at all. When I tried to ping localhost, it said:
Unable to contact IP driver, error code 2.
When I tried to do ipconfig, I got:
An internal error occurred: The request is not supported.
Additional information: Unable to query host name.
After some digging through event logs and Google, I found the problem. The virus had damaged some drivers, specifically c:\windows\system32\drivers\IPSec.sys. That file was completely missing, so when I replaced it and rebooted everything started working again.