Was beginning the introduction of Windows Server 2019 to a work environment and ran into some hurdles that were easily cleared, but want to share…
To begin with, you need to have a Volume Licensing agreement with Microsoft. We did and so I jumped into the MS Volume Licensing Service Center (VLSC) portal to grab our Client Specific Volume License Key (CSLVK) Key Management Service (KMS) key.
The CSLVK KMS key is what gets loaded into the KMS server. It’s basically your volume license key that gets hosted internally. The servers and desktops then use a Generic Volume License Key (GVLK) which let the machine know it needs to find and activate against an internal KMS resource and not go out to activate against Microsoft’s servers.
Apparently even if you have the Volume Licensing agreement, MS doesn’t automatically issue the CSLVK KMS key to you in your portal. You actually have to call them, verify some info, and have them generate a key for you which will then show up in your portal. The whole process took just under 5 minutes for me, and I was able to verify that I saw the key in my portal while I was still on the phone with MS.
To contact them I called 1-866-230-0560, option 4, option 1. That got me directly in contact with a representative that was able to issue the key. (Note: Menu options may change, I called in February 2020)
Jumping back into my KMS server, i tried to import the key directly into VAMT, also known as the Volume Activation Management Tool. This failed. I tried a couple more times, I even reinstalled the VAMT tool from the ADK toolkit. Nothing worked. Apparently though, I found out that this is a know issue. https://docs.microsoft.com/en-us/windows/deployment/volume-activation/vamt-known-issues
The workaround was to the slmgr.vbs tool. Entering the command below, allowed it to get added successfully. Replacing <CSVLK> with my actual key issued by MS. After entered, you’ll see a pop-up message stating that the key has been successfully added.
slmgr.vbs /ipk <CSVLK>
Once I had added my CSLVK, I was able to jump back into a new Windows Server 2019 virtual machine that I had created and use the slmgr.vbs command below to successfully activate the new virtual machine against my KMS server.
MDT is a powerful tool but it really needs an operating system, to deploy or capture, if you really want to utilize it’s full potential. Match that with Microsoft’s release schedule of Windows and you will find yourself needing to import a new OS at least once year, if not more. Today we’re going to take a look at importing Windows 10 v1909 into our MDT server.
The first thing that you will need to do is acquire a Windows Installation ISO or or use a captured custom install. Ultimately, we will need a file that is in the Windows Image (.WIM) format. FWIW – Microsoft has been using the WIM format in it’s installation media (DVDs and ISOs) since Windows Vista. Once you have acquired your installation media, either insert your DVD into your machine, or mount the ISO file so it can be accessed.
Open your Deployment Workbench and open the deployment share that you wish to import the OS into. Drill down into it’s folder and click onto Operating Systems. In the Actions pane on the right side of the console, click on New Folder, and create a folder appropriately named for the OS you wish to import and complete the wizard. I’m only importing the 64-bit iso, but if you were import both 32-bit and 64-bit, you might want to specific that in the folder’s name.
In the Deployment Workbench, right-click onto the new Windows 10 folder that you just created. Once selected, Import Operating System.
That will open the Import Operating System Wizard. Unless you are using a custom installation file, you will be selecting Full set of source files to import the WIM file from your DVD or ISO, then click NEXT.
Select your source folder. As i mentioned above, this will be your DVD or mounted ISO, click OK, then click NEXT.
Give your Destination directory a name and click NEXT.
Click NEXT on the Summary page.
You’ll see a progress window as MDT imports your OS.
When the import is complete, you see a message the the process was successful and you can click FINISH.
Because I’m importing from an ISO that has Enterprise, Education, and Profession in it, you can see that that it imported about ten different WIM files. Thats okay… We can delete the versions which we know we won’t use. Select and highlight the versions that you don’t want, right click and select Delete.
There will be a wizard that you can click NEXT through to complete the removal of the unwanted versions of the OS.
That completes importing an OS into MDT. Now we can use the newly imported versions of our OS in our Task Sequences.
With the end of support for Windows 2008, it was time to get those last few lingering services migrated to a new server. For me, one of those lingering tasks was to move our Print Server. This article will take a dive into what you need to do to migrate your Print Server to Windows 2016. This should work for all current versions of Windows Server.
The process of migrating your print server is done by utilizing the Printer Migration Wizard. The wizard tool allows you to export all the drivers, printer settings, and print queues from the source server into the export file. You can then import that file on the destination server, which will add in all those printer resources. The final step I’ll go over will be the removal of the original source print server and setting the new print server to the same name and IP address as the original source server. This is to make it a “seamless” transition on the back-end, so that clients can continue to print without changing any of their settings. They’ll never know you made a change! If you can’t assign you new server with the same name and IP, then you will to reconfigure all of your clients, either manually or via GPO
Configuring your new Print Server
Spin up your new server. Run thru a basic setup and apply any needed updates and patches to it.
Once you have it updated, fully patched, and ready-to-go we can proceed with setting up the Print-Services role by running the following PowerShell command. Install-WindowsFeature Print-Services Next we will start the Print Spooler service with the following commandSet-Service -Name "Spooler" -StartupType automatic Start-Service -Name "Spooler"
Next step is to enable a few firewall rules to allow for you to remotely manage your new server. Enter these commands into your Powershell window; Enable-NetFirewallRule -DisplayName "Windows Management Instrumentation (DCOM-In)" Enable-NetFirewallRule -DisplayGroup "Remote Event Log Management" Enable-NetFirewallRule -DisplayGroup "Remote Service Management" Enable-NetFirewallRule -DisplayGroup "Remote Volume Management" Enable-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" Enable-NetFirewallRule -DisplayGroup "Remote Scheduled Tasks Management" Enable-NetFirewallRule -DisplayGroup "Windows Management Instrumentation (WMI)" Enable-NetFirewallRule -DisplayGroup "File and Printer sharing"
Alright… your new print server is ready to proceed.
Exporting your Source Print Server Settings
On your new print server, start the Print Management console.
From the console, right click on Print Servers, and then click on Migrate Printers.
Select Export printer queues and drivers to a file, then click NEXT.
Enter the name of your source print server, then click NEXT.
You’ll be presented a list of the resources that will be exported, click NEXT.
Select a name and location on your new print server where you want to save your printer export file, then click NEXT.
The export process may take a few minutes to complete. You will end up with all of your printer resources from the source print server in a file. Also, something to note is that it can become a large file. My export file with just over 40 printers was 1.15GB.
Importing your Print Server Settings
From the Print Management console, right click on Print Management, then click on Migrate Printers again to begin the Migration Wizard.
This time we are going to choose Import printer queues and printer drivers from a file, then click NEXT.
Specifiy the path the file you created in the Export task , then click NEXT.
Windows will parse thru the file to load its’ printer objects, and give you a list to review, if it looks correct, click NEXT. Select This print server (\\PrintServerName) and click NEXT. Select Import mode: Overwrite existing printers, and List in the directory: Don’t list any printers , then click NEXT. We select to not list them, because they are already published in Active Directory by the source print server, and we would rather not make duplicates.
Once you have completed the import process, you will be prompted by the wizard to view the event log for any errors that might have happened during import.
If you encountered any “problem” drivers, go ahead and manually install them on your new server now.
Time to Switch Over to the New Print Server
We that we have all of our printers installed on our new printer server, it’s time to proceed with the next steps. Here we need to do three things. First is to remove the printers listed in by the source print server in Active Directory. Next we’ll rename our servers. Lastly we’ll re-add our printers from the new print server back into Active Directory.
On your source print server, open your Printer Management console and select all of your Printers. Right click on them and then select Remove from Directory.
Now proceed with renaming your source print server to something else, and assign it’s original name to your new print server. After our new print server has be given the original server’s name, reboot it so that the name change takes effect. We’re all done with the source print server, and will only be working on the new print server from this point.
Open the Printer Management console and select all of your Printers. Right click on them and then select List in Directory.
This will re-publish all of the printer back in Active Directory and complete our task of migrating the Print Server to a new server. And Viola! Just like that you should be back in business – able to print again until your heart is content or you run out toner, whichever comes first.
I recently had to migrate some services from an old Windows 2008 server to Windows 2016. One of those services was a Network Policy Server (NPS) service, which is used by RADIUS to authenticate users into some more secure resources.
I was kind of dreading the task, as I had no recollection of how I had configured it, some five or more years ago. My initial search on the subject landed me on this Microsoft documentation site, which was very informative. Luckily, the task of exporting and migrating your NPS configuration to import onto another server is quite simple. It can all be done with a few lines at a command prompt and a single XML file.
In Windows 2008 or 2008 R2, you use ‘netsh’. In Windows 2012 and above, you can use PowerShell or ‘netsh’.
Both methods are equally simple, it really just comes down to which version of Windows Server are you migrating from.
Export and Import the NPS configuration by using Netsh
Log into to your source NPS server with your Administrative credentials.
Open a ‘Command Prompt’ as an administrator, type netsh, and then hit Enter.
At the netsh prompt, type nps, and then hit Enter.
At the netsh nps prompt, type export filename="<path>\<filename>.xml" exportPSK=YES Update <path> with the folder location where you want to save your configuraation file. The path can be relative or absolute, or it can be a UNC path. Update <filename> with what you want to name your xml file.
After you press Enter, you’ll see a message showing whether the export was successful or not.
Copy the xml file you created to the destination NPS server.
Open a ‘Command Prompt’ as an administrator on the destinantion NPS. Type the following command, then hit Enter. netsh nps import filename="<path>\<file>.xml" A message will appear to show whether the import was successful or not.
Export and Import the NPS configuration by using Windows PowerShell
Log into to your source NPS server with your Administrative credentials.
Open a ‘PowerShell window’ as an administrator, type the following command, and then hit Enter. Export-NpsConfiguration –Path c:\NPSconfig.xml
There is no message after the command completes, but if you check your path location, you should see your xml file.
After you have exported the NPS configuration to a file, copy the file to the destination NPS server. I’m copying mine to the root of the c:\ so it’s easy to find.
Open a ‘PowerShell window’ as an administrator on the destination server. Type the following command, and then hit Enter, to import your configuration.
This was fun… Lets update Windows. Okay, done. Now lets open VMware Workstation and get back to work on that vm that I needed to do something on…
VMware Workstation Pro can’t run on Windows
Check for an updated version of this app that runs on Windows.
Compatibility Assistant
What the!!! Umm, I’m not re-purchasing Workstation, I just bought it a couple months ago! 🤬 😤
If you have tried running VMware’s Workstation Player/Pro version 12 or 14 on Windows 10 1903 (or above), there’s a pretty good chance that you went through the same conversation with yourself that I did above. Apparently the release schedules for Windows 10 and for Workstation, don’t align, and older releases of Workstation will get put on a sort of program “blacklist”.
As part of a MS Cumulative Update (Sept 26, 2019; OS Build 18362.387+), it will update a database of programs that are prohibited by MS. Their “Compatibility Assistant” component now prevents older versions of Workstation from even running. So how do we get around this and use Workstation?
The best solution would be to become a paid “Advantage” member of the VMware User Group (VMUG). By spendign $200 and becoming an VMUG Advantage member, one of the biggest perks is that you get access to evaluation licenses of basically all of VMware’s products. So, you can download, install, run with the most current and non-“Compatibility Assistant” blocked version of Worstation.
Okay, so you don’t want to spend any additional money. I totally understand. In that case, the simplest way to fix this is going to be to make a registry edit. The registry edit is necessary to override the “Compatibility Asisstant” default behavior, thus allowing us the ability to run Workstation again.
Backup your registry… Disclaimer: I’m not responsible for any unintentional mishaps you have while you edit your registry.
Open a text editor, and copy/paste the code below into it.
Save it as a ‘.reg’ file. Go ahead and name it something like “VMworkstation.reg”.
Open and apply your “VMworkstation.reg” file to modify your registry.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags]
"{3d9912c3-cb54-4f34-ab71-1d429553bf96}"=dword:00000077
"{66f21bbc-149a-411b-8e11-880af7c1266c}"=dword:00000077
Note: This method is also suitable to deploy via Group Policy.
The last option available, would be to replace the “Compatibily Assistant” database file with an older version of itself. I’m personally not a fan of this method, so I’m not going to expand on it. But with a little googling you can learn how this would be done.
After changing over from on-prem Exchange to O365, I had one user where the recipients of their emails would receive any attachment that was sent as the “dreaded” winmail.dat file instead of the .pdf or whatever file the user was actually sending. It was intermittent however, in that some users would get the actual file and some (all external) would get the winmail.dat file.
First thing that I did was check that user was sending their mail as HTML, and not Rich-Text. After changing that value, I check back a week or so later and the user was still experiencing the issue, so it was time to dig a little deeper. After some searching online I was able to find that this was not an uncommon issue.
The issue happens because the receiver’s email client can not interpret the email message that was sent from Outlook in the Rich-Text format. When using Outlook to end an email using the Rich-Text format, a plain text copy of the email is also sent along with an attachment named winmail.dat. This ‘winmail.dat’ attachment is what contains all of the formatting, elements, and other data specific to Rich-Text email messages. This method of sending the email message is called “Transport Neutral Encapsulation Format” or “TNEF” for short.
Unfortunately, many non-Microsoft email programs can not properly open message that are received in TNEF. To fix this, we can use PowerShell to force Exchange Online to convert Rich-text messages to HTML before it sends it off. You can use the commands shown below to set the ‘RemoteDomain’ property “TNEFEnabled” to false on the Default policy.
1) Connect to Exchange Online via Powershell.
2) Get your Default RemoteDomain policy: Get-RemoteDomain | fl *
3) Set the TNEFEnabled property: Set-RemoteDomain Default -TNEFenabled $false Re-run step 2 and you should see that “TNEFEnabled” is set to “False”.
Just in case… Here is how to change it back to a NULL value to undo your change in step 3, and let the Outlook client again decide how it wants to send the message.
4) Set the TNEFEnabled property back to NULL: Set-RemoteDomain Default -TNEFenabled $nul
I was running an MDT LiteTouch deployment and the computer kept getting stuck at a command prompt after loading into MDT environment. Normally it should have launched right into the LiteTouch wizard, but for whatever reason, it just didn’t want to go beyond this point on its own. I discovered two possible ways to circumvent it.
I had used this same means of deployment on other machines of the same make and model, with the same Task Sequence, so I knew it wasn’t a driver issue as many eluded to in the various forums I looked at. However, I went ahead and did an “ipconfig” and also tried to mount the MDT share using “net use“, just to make sure there was no network issues. net use z:\\<servername>\deploymentshare$ Well, it turned out that I did already have an IP address and the mapped drive was already in use. So how can I now get on with my deployment?
The first and possibly the easiest way was to just manually launch the LiteTouch. It is as straight forwards as it sounds. I entered the command below into my command prompt, and viola! The LiteTouch wizard came right up and I continued on my way. X:\windows\system32> Z:\scripts\LiteTouch.vbs
The second method, really isn’t any more difficult than the first. Sometimes a folder named “MININIT” already exists on the computer’s C: drive and it can cause issues when trying to do a new deployment. The way around that is just to wipe the drive and essentially start back at square one. Warning though – Following this method WILL erase the drive and wipe any data that is on it. While it probably doesn’t matter, as you’re stuck anyways, but it is just something to be aware of.
At the first Wizard window, press F8. Then type:
Diskpart (enter)
List disk (enter)
Select disk 0 (choose your main OS disk) (enter)
Clean (enter)
Reboot and start your imaging process again.
After wiping the disk of any pre-existing partitions your next deployment attempt should go smoothly as it now has a blank HDD to work on.
I was reformatting a drive for some Veeam backups and was trying to recall what I had set the ReFS allocation unit size to when I initially setup the drive. Well, I could not remember to save my life. Luckily, with a little command line action, it’s easy enough to find out what it was set it to.
The command line tool to use is fsutils. To see what options are available to us when using fsutils, we can run the following command.fsutils fsinfo /?
Using “E:/” as the drive we are checking out, we can run the following line to discover information about the volume itself. fsutil fsinfo volumeinfo E:
To view the specific ReFS info on this drive, we can run the following line. fsutil fsinfo refsinfo E: Take a look at value for the “Bytes Per Cluster”, this is where we can see that when this drive was formatted, it’s allocation unit size was set to 65k. 65k is also the recommended setting for Veeam destinations if you are using ReFS.
Out of an entire organization, we had one single machine that had issues installing O365, it would always get stuck at “51%”. I even let tried letting it run for an entire weekend. The weird part was that it was a Win10 machine, and it was all up-to-date in terms of applying Windows Updates. The same ODT script worked perfectly fine for all the other machines that were a mix of Win8.1 & Win10.
So I gave the Office 365 uninstaller a whirl. It ran thru pretty quickly and said everything was removed. It ran so quick, it didn’t even seem like it did anything. I went ahead and tried my ODT script again. and voila – It worked!
So my only take away, is if you’re having issues with the installer “stalling” out, try MS’s uninstaller and try your install again.
Multi-factor authentication is something that you should have enabled in your Azure or Office 365 tenant. It’s going to solve at least 90% of your problems about worrying if someone is going to ‘hack’ into your organization. That said, it can provide a few headaches of it’s own.
When your user is choosing their methods or means to authenticate, one of the options is to use their “Office Phone”. That great… But if you sync your on-prem AD to AzureAD then you’ll quickly realize that that option is grayed out and you can’t set it. You’ll get some message about contacting your administrator.
To set this number, simply edit the properties of your user in your on-prem AD.
Open “Active Directory Users and Computers” and navigate to your user.
Right-click on the user and choose ‘properties’.
Under ‘Telephone’ enter the user’s phone number, country code first, like either of the examples below.
+1 8085551234
+1 8085551234 x123
Click ‘OK’ to save the edits.
After you have finished editing the user, all you have to do is wait for next sync cycle. From then on, your users will be able to authenticate and login by using their work desk phone.
