I.T. Giffen.cloud | my useful/less byte of technology

4 March 2020

MDT & Joining the Domain

An important part to any OS deployment is joining the computer to the domain. The whole point of Microsoft’s Deployment Toolkit (MDT) is to automate as much of your deployment process as possible. So it is no surprise that MDT, when properly configured, can automagically join your newly deployed machine to the domain. It’s actually pretty easy to setup.

Part 1

The first part of allowing MDT to join machines to the domain is to setup a unique service account specifically for the task of joining machines to the domain.

Microsoft has helped to make things easier for us and has created a PowerShell script that can be downloaded, placed on your Domain Controller, and run to set a service account up with all of the necessary account permissions to manage computer objects in a specified OU. The script and instructions can be found under ‘Step 1’ at this link: https://docs.microsoft.com/en-us/windows/deployment/deploy-windows-mdt/deploy-a-windows-10-image-using-mdt

Part 2

The second part is going to be adding the correct values into your CustomSettings.ini file. There are the four variables that we need to add to automate the domain join, and one recommended value to skip the corresponding Domain Membership page in the Task Sequence wizard;

JoinDomain = The domain we are wanting to join.
DomainAdmin = The username of the service account we created earlier.
DomainAdminDomain = the domain that the service account resides. It’s typically going to be the same as the ‘JoinDomain’ value, but depending on how your AD Forest is configured, it is possible that it could be a different domain.
DomainAdminPassword = The password to our service account.
SkipDomainMembership = Yes/No. A ‘Yes’ value will skip the wizard page that asks about domain membership. A ‘No’ value will show the domain membership page.

Here is an example of how it would look when entered into the CustomSettings.ini file.

JoinDomain=MyDomain.tld
DomainAdmin=MDT_DJ
DomainAdminDomain=MyDomain.tld
DomainAdminPassword=Abc123456&!
SkipDomainMembership=YES

One additional item you may want to add to your CustomSettings.ini file is a value to specify which OU object you want the newly joined machine to be added to.

MachineObjectOU = Active Directory OU object you want machines to added to. It’s where you would have specified when creating the service account and running MS’s PowerShell script.

Which would look like this in the CustomSettings.ini file.

MachineObjectOU=OU=Workstations,OU=Computers,DC=MyDomain,DC=tld

You’ll want to make sure the OU is properly set for your domain. However, if you prefer to not specify an OU, your machines will all end up in the default ‘Computers’ OU of your domain, no harm there, you will just need to then manually move them into their correct OU.

Here’s what all the combined values I covered in this post would look like when added to the CustomSettings.ini .

JoinDomain=MyDomain.tld
DomainAdmin=MDT_DJ
DomainAdminDomain=MyDomain.tld
DomainAdminPassword=Abc123456&!
SkipDomainMembership=YES
MachineObjectOU=OU=Workstations,OU=Computers,DC=MyDomain,DC=tld

With the service account setup and the values added to our CustomSettings.ini, your deployments should now have no problems getting joined to your domain. Congratulations! You’ve streamlined one more deployment task.

Category: Microsoft | LEAVE A COMMENT

27 February 2020

Server Manager – Orphaned RDS

So I’ve seen this a couple times and I always forget how to handle it, so hopefully writing this down will help me remember for next time…

You are replacing some Remote Desktop Session Host (RDSH) with a newer server, and everything looks good-to-go. Back on your Remote Desktop Connection Broker (RDCB), you have Server Manager open, and you proceed to remove the old RDSH servers. Easy. You then go back to edit other properties in in your RDS deployment and – BAM – you get an error message that states:

The following servers in this deployment are not part of the server pool:
1. <Old.RDSH.ServerName>
The servers must be added to the server pool

Powershell to our rescue! On your RDCB, open up a PowerShell window as an Administrator. Run the command below.

PS C:\> Get-RDServer

This will return a list of all the Remote Desktop servers you have in RDCB as well as their installed roles. You should see your old, unwanted, RDSH server in that list. Next, we can enter the command below to remove our orphaned RDSH server.

PS C:\> Remove-RDServer Old.RDSH.ServerName RDS-RD-SERVER

This will remove the ‘RDS-RD-SERVER’ role. Now if you go back to your RDCB, and back to your deployment, everything should be back to normal. It is no longer expecting the “Old.RDSH.Server” to be a server that Server Manger manages. In fact, at this point you should be able to remove it as a managed server.

Note: RDS is a complicated beast. The above mentioned trick utilizing PowerShell has worked for me the couple times I’ve needed in my scenario. However, your mileage may vary depending on your environment.

Category: Microsoft, PowerShell, Windows 2012/2012R2, Windows 2016, Windows 2019 | LEAVE A COMMENT

21 February 2020

iDRAC Firmware & BIOS updates

Today I got to push some updates to some physical Dell servers. Instead of updating everything with a SmartBootable ISO, like i usually do, I used the servers’ iDRAC to push only the individual updates these Dell FC630s needed. It saves some time which is ultimately what i was after.

Head on over to the DellEMC Support page, type in your server’s Service Tag, and find the various updates you need. Alternatively, you can also use the DellEMC Repository utility (which you host internally on your own server or vm) to pull down your updates for the hardware you specify.

Server BIOS updates

The good news for us is that you can download the windows .exe file version of the BIOS update. Even if your physical host is a ESXi or Linux server. The iDRAC is smart enough to extract the bios file it needs from the .exe file you downloaded.

Once you have your BIOS .exe file. Open up the iDRAC webgui for your server. In the left hand side, Click on “iDRAC Settings”. Then click on “Update and Rollback”.

You will see a box to use to upload your file to the server. For File location, select “Local”. Then click on “Choose File”. Navigate to the file you downloaded and select it. Click “Upload”

You’ll see you the status of it uploading.

After it has uploaded, you have two option in the lower right corner of that box. You can choose to “Install and Reboot” the server now, or “Install Next Reboot” where you’d have to reboot the server later at a more convenient time. Choose which works best for you.

Note: Remember to pause workloads on your server if you choose to reboot now. ie – If its an ESXi server, put it in maintenance mode. As iDRAC doesn’t really care about the state of your VMs, it just wants to initiate the reboot.

Once you click “Install and Reboot” you’ll see the iDRAC push/download the file to the server and initate it’s reboot. Below are some screenshots from the “Install and Reboot” process

If you selected “Install Next Reboot” you’ll see the job listed in the “Job Queue” as scheduled.

Once you manually reboot your server, if you are watching the it’s console, you will see the update get applied.

iDARC Lifecycle Controller

The process is very similar for updating the iDRAC’s firmware on the server. Go to the DellEMC Support page (or your DellEMC Repository) and download the .exe update for the iDRAC.

On you Windows workstation, double click on the file to run it. Let it extract it’s files, noting where they are saved to. Navigate to that folder and look for the folder named “payload”. Double click on the “payload” folder, and look for the firmimg.d# file. For my servers, they’re running iDRAC 8, so the file is going to be .d7.

Open up the iDRAC webgui for your server. In the left hand side, Click on “iDRAC Settings”. Then click on “Update and Rollback”.

You will see a box to use to upload your firmimg.d# to the server. For File location, select “Local”. Then click on “Choose File”. Navigate to the extracted .d# file and select it. Click “Upload”

After the upload completes you’ll see the same two options I mentioned earlier in this post “Install and Reboot” and “Install Next Reboot”. Pick which ever works for you to complete your iDRAC firmware update.

Other Updates

This same process will work for other firmware updates you need to push to your hardware too. I’d suggest following the same instructions that were used for the BIOS update. In most cases, iDRAC is smart enough to extract the necessary files it needs to apply the update. If it doesn’t work, you can try extracting it yourself.

Thats it!!! Hope that this post helps you keep your DellEMC hardware all up to date!

Category: Dell Hardware, Hardware | LEAVE A COMMENT

19 February 2020

MDT Screen Resolution Setting

Johan Arwidmark is basically a guru in the world of Windows deployment. His blog (deploymentresearch.com) is a literal treasure trove of information for all things deployment related and it is where I found this tip.

By editing your CustomSettings.ini file you can actually set the resolution values to be written to your unattend.xml file during deployment. How handy is that!?!

Set the resolution to 1280×1024

[Settings]
Priority=Default

[Default]
BitsPerPel=32
VRefresh=60
XResolution=1280
YResolution=1024

Even cooler is the fact that you can actually set it to auto detect the resolution.

[Settings]
Priority=Default

[Default]
BitsPerPel=32
VRefresh=60
XResolution=1
YResolution=1

The auto detection works because Windows realizes how silly it would be to have a screen resolution that was only 1×1. Now that’s a neat trick!

Category: Microsoft | LEAVE A COMMENT

14 February 2020

UEFI, NTFS, and Bootable USB

When using Microsoft’s MDT for deployment, sometimes you need to create a bootable USB to boot your machine into a LiteTouch deployment. Well Thanks to an application named Rufus, that could not be any simpler. Rufus is a utility that helps to format and create bootable USB flash drives, such as USB keys/pendrives, memory sticks, etc.

After creating your MDT iso, copy it onto your workstation, or whichever machine you are creating the bootable USB on.
Download and install Rufus (at the time of writing this is at v3.8). https://rufus.ie/
In Rufus;
- Select your USB from the Device dropdown menu
- Click on SELECT, and choose the MDT iso you copied to your workstation
- If desired, modify the Volume_Label to the name of your preference
- Under the File system dropdown menu, select NTFS
- Click on START to begin formatting your device

Now, as long as secure boot is disabled, you can boot direct from your UEFI enabled thumb drive and get to your MDT task sequences.

Category: Microsoft | LEAVE A COMMENT

13 February 2020

Window 2019 KMS key and VAMT

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.

FWIW – you can find all of the GVLK product keys here – https://docs.microsoft.com/en-us/windows-server/get-started/kmsclientkeys

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.

slmgr.vbs /ato

Category: Microsoft, Windows 2019 | 4 Comments

31 January 2020

Importing an OS into MDT

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.

Category: Microsoft, Windows 10 | LEAVE A COMMENT

24 January 2020

Migrating Print Server

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.

Category: Microsoft, Windows 2012/2012R2, Windows 2016, Windows 2019 | 3 Comments

23 January 2020

Migrating NPS Configuration

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.

Import-NpsConfiguration -Path "c:\NPSconfig.xml"

Category: Microsoft, Networking, PowerShell, Windows 2012/2012R2, Windows 2016, Windows 2019 | 9 Comments

17 January 2020

VMware Workstation can’t run on Windows

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.

Category: Microsoft, VMWare, Windows 10, Workstation | LEAVE A COMMENT