Most companies will use a certificate to sign their applications before they release their software to the world. This helps the user know to that the software they are running actually came from the software vendor, and hasn’t been altered or changed by someone.
Certificates are based on key pairs. There is a public key, and a private key. In terms of digitally signing an application, the public key is often just referred to as the Certificate.
How it works, in simpified terms… The software vendor holds a private key, and they guard it, keeping it safe in their organization. You can also think of is their fingerprint that they’ll use when signing something as it is unique. The public key is what we can see. Using a hash in the digitally signed application, we can use their public key, to see is if the hash value can be verified. If it checks out then we know that the digital signature is valid. If it doesn’t, well then we know the signature has been altered.
The I’ll show you below how you can pull the public half of the Certificate from an application. In this example we’ll pull Adobe’s certificate from Adobe Reader DC.
Right click on the application you want the signature of and select “Properties”
Click the “Digital Signature” tab, select the signature, then click the “Details” button.
Note: If you do not see the “Digital Signature” tab, then the file is not digitally signed.
Click the “View Certificate” button.
Click the “Details” tab and then select the “Copy to File” button.
Follow the “Certificate Export Wizard”.
After completing the export wizard, you’ll have the digital signature certificate of the digitally signed application.
Using GPOs is a great way to allow or block programs from running on your corporate network. Just be careful and limit yourself to only blocking the applications which you actually have a need to block. Don’t go too crazy locking down programs
Microsoft first made the introduction of “Software Restriction Policies” in Windows Server 2008 and they’ve continued to evolve. Today I will show you four ways which Microsoft allows us to restrict programs from running.
File Path / File Name Rule
Network Zone Rule
Hash Rule
Certificate Rule
To begin, fire up the Group Policy Management Editor. Click on the start menu and type “gpmc.msc”. If you are on a Domain Controller it should work. If you’re on a workstation you’ll likely have to run Server Manager as a Domain Admin (or other user with the correct administrative privileges), choose “Group Policy Management” from the ‘Tools’ dropdown.
Once it’s open, scroll down to the folder “Group Policy Objects” and right-click on it to create a “New ” policy object. Give it an appropriate name, something like “Software Restrictions – Test”. Now find and right-click on your new policy and select “Edit…”.
The software restriction policy exists under both “Computer Configuration” and “User Configuration”. So depending on your needs, you can lock down either the user or the computer.
Drill down into the policy… “Policies” -> “Windows Settings” -> “Security Settings” -> “Software Restriction Policies”.
Right-click on “Software Restriction Policies” and click “New Software Restriction Policies”
Select and open the “Additional Rules” folder.
Right-click under the two pre-existing default entries, and then from that drop-down menu select the type of rule you want to create. I’ll expand on the four methods below…
There are three security levels used in all of these rules:
DISALLOWED: Software will not run, regardless of the access rights of the user.
BASIC USER: Allows programs to run only as standard user. Removes the ability to “Run as Administrator”.
UNRESTRICTED: No changes made by this policy – Software access rights are determined by the file access rights of the user.
My examples below all show how to block software with ‘dissallowed’ rules. But just remember that you can just as easily allow for software by using ‘basic user’ and ‘unrestricted’ rules. Use them wisely!
1. Block by File Path / File Name Rule
In this example I will show you how to lock down the computer from running WordPad.
Select “New Path Rule”.
Type, or use the “Browse…” button, to enter the file path or file name you wish to block. Make sure that the ‘Security level’ is set to “Dissallow”. Then click ‘OK’.
Note: System variables will all function in the rule, variables such as %windir%, %ProgramFiles(x86)%, %AppData%, %userprofile%, and others.
It is important to note that many applications launch in more than just one way. So you may have to block multiple executables to fully block the application, just fyi.
You also need to take note of where/how software get launched from, as some applications have multiple ways they can be launched. Just FYI, in case you start banging your head as to why some block rule doesn’t seem to be working.
Also be careful using just the file name itself to try to block a program from running. If you were to block just the file name ‘update.exe’ for example, hundreds of applications all ship with an ‘update’ executable and they would all be hindered and unable run.
My rule of thumb is to always use the full path unless it’s truly a unique file name, and even then I still prefer to use the full path.
2. Block by Network Zone Rule
Select “New Network Rule”.
Select the Network zone you want to block. Make sure that the ‘Security level’ is set to “Dissallow”. Then click ‘OK’.
These rules allow you to block programs if they come from sites you’ve designated into a zone, like your Restricted sites. Or in the case that you were to be creating an allow rule, your local Intranet. While this option exists, it seems unlikely to me that most SMBs ever use it.
3. Block by Hash Rule
In this example I will show you how to lock down the computer from running WordPad.
Select “New Hash Rule”.
Use the “Browse…” button to navigate to the file which you are wanting to block. Select the file and click ‘Open’. It will automatically pull the needed file information and the “hash” it needs from the file you selected. Make sure that the ‘Security level’ is set to “Dissallow”. Then click ‘OK’.
The only problem this method has is that file hashes change any time there is ANY change to file. It doesn’t matter how small of a change is made, it will always create a new hash. That means that hash rules are best applied to older software that you are trying to kill, and not for programs that get updated often.
4. Block by Certificate Rule
In this example we will be blocking applications signed by Adobe Inc.
Select “New Certificate Rule”.
Use the “Browse…” button to navigate to the certificate file which you are wanting to use to block signed software. Select the file and click ‘Open’. Make sure that the ‘Security level’ is set to “Dissallow”. Then click ‘OK’.
Certificate rules are by far one of the most secure rules as they rely on certificates from trusted publishers. Because of this but they require more work on the PC’s part as it goes out and tries to verify the validity of the certificate, so they may significantly effect performance. I can’t tell you how much of an impact they’ll create, but it’s enough that MS warns us. Also, if the certificate ever expires, you’ll need create a new rule.
The Quick Access links is a feature in Windows that gives the user an easy way to access the folders which use frequently by pinning them to the top of the left pane in ‘File Explorer’. Sometimes the file that stores the pinned items can get corrupted and thus you loose access to the Quick Access pinned items. Here’s a few ways to fix it.
Method 1
We can reset the Quick Access Recent Items. This method will only apply to “stuck” recent folders, and won’t affect your pinned folders.
Right click on the Quick Access star icon and then click on ‘Options’.
Click the ‘Clear’ button under ‘Privacy’.
All of your Recent folders will be cleared from the Quick Access list.
Method 2
This method will reset and clear the Quick access shortcuts. But in my opinion this is the better way to fix it, as you can always re-pin your shortcuts.
Open File Explorer and copy/paste the following folder location:
Look for and then delete this file from the folder:
cmd.exe /c del “%AppData%\Microsoft\Windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms”
*Or you can open a ‘Run’ dialog (Windows key + R) and copy/paste the following command into it to delete the file.
cmd.exe /c del "%AppData%\Microsoft\Windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms"
This method will remove and clear any custom pinned items and frequent items from the Quick Access list. Windows will automatically regenerate the “f01b4d95cf55d32a.automaticDestinations-ms” file the next time that you launch File Explorer and wil list the default Quick Access links which you can expand upon.
A bad user profile could happen to any one of your users. It could happen in Windows desktop or on a server. The user will log in and instead of their profile getting loaded, the OS decides it wants to load a temporary profile the the user. The user will a pop up message stating “You have been logged on with a Temporary Profile” and that any changes won’t get saved.
It can be frustrating for the user, for sure. However, once you know where to go to fix it, it’s not too big of a deal.
Why does it happen? Well there are a variety of reasons. It could be corrupt. It could be delayed, likely from an antivirus program, or some service not responding, or many other operations. Once Windows has loaded a temporary profile for a user, it will continue to do so. That user will always load their temporary profile until you fix it.
How to fix it? You can try to reboot the computer. Depending on whether this is a desktop or server, that may or may not be an easy task to try. If that doesn’t resolve the issue, follow my steps below to fix it. It should work in almost all cases.
1. Login as an ‘Administrator’ to the machine.
2. Click the start button
3. Type “reedit” and then right-click on program to ‘Run as Administrator’. Click ‘Yes’ to any UAC pop up.
5. You will see a list of all of the profile names. Two will be named the same, with one of them ending with “.bak”.
The temporary profile does not have the ‘.bak’ at the end of it. The original or “old” profile has the ‘.bak’ at the end of it.
6. Now that we know which profile is which, we need to rename them.
We need to rename the temporary profile by adding a ‘tmp’ to the end of it.
Next we will rename the original profile by removing the ‘.bak’ from the end of it.
7. Reboot the computer to complete the process.
8. Log back in as the affected user and it should now load the original profile.
9. Once the original profile has been restored, as an administrator you can re-open the regedit tool and navigate back to the same entry from “Step 4”. Right-click on the temporary profile that ends in ‘.tmp’ and select “Delete” to permanently remove it.
If the did not help, then your only other option would be to create a new user profile. To do this, you’d need to, as an administrator, delete the user profile before having the user log back onto the machine. Everything such as user documents and files would be lost though. Hopefully you have a good backup of your data that you restore from.
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.
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.
