I got tired of googling this every time I make a new collection, so I figured it was time for my own post. I am now using SCCM for work, so I have had to learn a few new tricks to make life easier. One thing I’m doing often enough is creating a custom device collection of computers. The slow and tedious way to do this is to individually add each machine. Blah! What a waste of time. To make it go as fast as possible, I try to already have an excel list of the machine names I want to add to the collection.
In my excel file, my list of machine names are in column A. I’m going to be using column B for the values I’ll copy into SCCM. The formula that we’ll be using to convert the names into the format that SCCM wants is:
=char(34)&A2&char(34)&","
Lets break that down to see how it will convert the name into a format that can be used..
Char(34) is going to give us the quotation marks we want on either side of our computer name.
A2, in this instance, is the cell that contains one of my computer names. You will have to adjust this cell reference to fit your excel sheet.
At the very end of it, we add a comma.
Once we have that taken care of, we can drag the corner of the cell down to apply that same formula to the rest of our list.
Below is the basic query we will be using and adding our formatted list of names to.
select * from SMS_R_System where SMS_R_System.Name in ( )
The end result, using the example list of computer names above, will look like this. The one thing to note is that you need to remove the very last comma from the list of computer names or you’ll get an error message when you try to save it.
select * from SMS_R_System where SMS_R_System.Name in ( "computer001", "computer002", "computer003", "computer004", "computer005", "computer006", "computer007", "computer008", "computer009" )
That is how you populate a SCCM device collection from an Excel list.
The Azure AD Connect tool has a default sync schedule to run every 30 minutes. However sometime you need changes you make to get sync-ed NOW! So from time-to-time it’s necessary to manually force Azure AD Connect to run and sync your on-prem AD up to Azure AD. This can be done with PowerShell as either a full sync or a delta sync.
Open Powershell.
If you’re running PowerShell on the server where AD Connect Sync resides, you can skip this step. Connect to the AAD Connect Sync server by running the following command to create a PSRemoting session. Replacing <SERVERNAME> with the name of your AD Connect server.
Enter-PSSession -ComputerName <SERVERNAME>
Import the ADSync module with the following command.
Import-Module ADSync
Run one of the following command to manually force the sync.
For a Delta Sync (most commonly use cases)
Start-ADSyncSyncCycle -PolicyType Delta
For a Full Sync (less common use cases)
Start-ADSyncSyncCycle -PolicyType Initial
If you used the “Enter-PSSession” command earlier, then you need to exit that session. Otherwise it will stay open even after terminating the connection. To close the “PSSession” use the following command:
So another gotcha when using O365 in hybird mode with on-prem sync is that you can’t hide a user’s email address [from address books and distribution lists] by using the Exhange Admin Portal. This is because the setting are made on-prem, and those defined values are simply pushing to your AAD tenant in Microsoft’s Azure cloud.
We used to be able to, from the Exchange Management Console on the on-prem server, just open the user and check a tick box to hide their address from everything. The work around isn’t much harder, it’s just buried deeper.
Open the user in your on-prem AD, and navigate the “Attribute Editor” tab.
Scroll down until you find the following attribute.
msExchHideFromAddressLists
Setting it to “TRUE” will make the email addess hidden.
Setting it to “FALSE” or “<not set>” will make the email address visible.
After you have made the desired change to the value of the attribute, you just need to wait for [or force] your on-prem AD to re-sync with your AAD.
If you use O365 in hybird mode, with your tenant sync-ed to your on-prem AD or Exchange server, then you will definitely run into an issue if you try to add an alias email address to a user.
When you attempt to add an alias, or alternate, email in your Exchange Admin Center portal you will see this error message.
To get around this you’ll need to edit the user “local” from your on-prem AD. In AD, right-click and open the users’ properties. Select the tab “Attribute Editor”
You will want to look for and edit the following two attributes.
msExchShadowProxyAddresses
ProxyAddresses
Add the user’s alias/alternate email address into the above mentioned attributes in the form of: smtp:updatedname@domain.tld
That’s it. Now you just need to let your AD sync back up to the O365 cloud.
WARNING: If you add it in CAPS (SMTP:updatedname@domain.tld) then it will get interpreted as the default address and not as an alias/alternate email. Make sure that “smtp” is lowercase.
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.
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.
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.
