Convert MAK licensed Windows system back to KMS

The back and forth Windows licensing from KMS to MAK can be so frustrating.  Today I had to take a system that had been KMS and then made MAK back to KMS again.  Of course this process involves searching for a variety of various scripts to run but you have to put a KMS key in even if you’re going to network provided KMS.  Apparently Microsoft makes available default KMS keys you can put in to swap back.

  1. Find your key from the website for the version you’re working with
  2. Start a CMD Command Prompt as an admin
  3. cscript slmgr.vbs /ipk KeyFromWebsiteAbove
  4. cscript slmgr.vbs /ato

The Windows interface updated to show my system was now activated again without having to close it.

Fixing broken replication after changing a Hyper-V host’s name

Changed the host name of a Hyper-V server and now all of your VM’s replication status is Critical?  In the past you’d have to break replication and then rebuild it for every single VM letting them resynchronize which is just an absolute pain and resource/time consuming.  Now we can use the PowerShell Set-VMReplication to fix the Replica Server’s changed name.  You might not notice this right away if the old DNS was left to linger in DNS for some time.  If it gets cleaned out automatically or someone deletes the old name your VMs might stop replicating.  Right clicking a VM and viewing the replication health look at the Current Replica Server to see if the name there is the old name.

Set-VMReplication VM-Name Replica-Server-Name

Luckily this takes * as a wildcard for the VM-Name letting you alter all of your VMs.  Examples;

Set-VMReplication VM01

Set-VMReplication *

Once the value is changed I reset the replication history and reset the Hyper-V Manager service.  I’m not 100% sure you have to restart the service but I did during testing because I missed one of the gotchas below before resolving it.

There are a couple of gotchas to watch out for.

  1. The system’s new name needs to be in DNS
  2. If you use SSL verification you need to make sure the SSL certificate has been updated to the new name
  3. If you use “Allow replication from the specified servers” option in the Hyper-V Settings of the host system you have to put the new system’s name in the allow list

STIG/CIS/Best Practices stops Acrobat loading PDFs from over the network

We’ve been running STIG configuration with Adobe Acrobat DC Classic & Continuous versions for a while with no issues until early 2019 when users started not being able to load PDFs from over the network anymore.  Acrobat would say it was blocking loading PDFs from the internet and then give the address it was blocking of SMB://FileServerName.Domain.Org/Path/EvilPDF.pdf which is clearly not on the internet.  It seems sometime in Feb 2019 an update to Acrobat altered this behavior.  The confusing part of this was that some users could continue to load PDFs from the same location while others could not.

  1. Firstly the reason for some being able to load them and others not being able to is because Acrobat is like Office in that it stores in the user’s registry trusted locations.  If a user added a document or location to their trusted locations prior to STIG/CIS/BP configuration being implemented on their system those allowances will continue to exist and be respected by Acrobat and Office in that user’s profile even though the usage of trust lists is disabled.
  2. Secondly the change in Acrobat that started this issue seems to only happen when the FQDN of a share server is used.  If you use \\ShortName\Path\EvilPDF.pdf or even \\IPAddress\Path\EvilPDF.pdf then Acrobat lets the file through without problem.  Once you use the FQDN Acrobat thinks you’re connecting to the internet.
The GPO is located at both of these locations depending on what version of Acrobat your support.
Computer Configuration -> Administrative Templates -> Adobe Acrobat Pro DC Classic -> Preferences -> Trust Manager
Computer Configuration -> Administrative Templates -> Adobe Acrobat Pro DC Continuous -> Preferences -> Trust Manager
The setting that causes the issue is this one;
Access to websites = Block PDF files access to all web sites
The problem is that now that this thinks FQDN shares are on the internet how do you allow them without allowing everything on the internet because there’s no GPO setting to designate between either.  Buried in the Adobe documentation is the registry configuration you can set to allow a white list of URLs in a REG_SZ called tHostPerms which has no corresponding GPO value.
The first step is to set the GPO value above Access to websites = Custom setting which tells Acrobat to then use the trust list we’re about to define.  The trust list lets you define allowed and blocked websites but when in Custom mode it will block everything except for what you place in the allow portion.  Then create a Computer Configuration -> Preferences -> Windows Settings -> Registry GPO entry for the following.
  • HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Adobe Acrobat\DC\FeatureLockdown\cDefaultLaunchURLPerms
    • REG_SZ = tHostPerms
    • Value = version:2|URL:#|URL:#|URL:#
      • # = behavior
      • 2 = allow
      • 3 = block
    • Example = version:2|FileServerName.Domain.Org:2||

Note 1: You have to leave the http(s):// off the front of the FQDN for it to work for SMB shares.  I tried using the smb:// notation but never got it to work in testing.

Note 2: the Adobe documentation states 1 is block but I found through actually creating block entries that 3 is what the latest Acrobat DC puts in the registry for that.

Once this populates out to your users they can once again open PDFs from the network shares when using FQDNs.

Active Directory user accounts keep losing inheritable permissions?

Do you have Active Directory accounts and use a password reset management tool like Thycotic’s Password Reset and out of the blue some accounts just stop being able to be managed?  We did and I stumbled across the solution while trying to resolve something else.  We were using another tool to discover “sensitive” accounts for targeting for other security changes and found this was returning accounts that were clearly not in any sensitive account groups.

Get-ADUser -Filter {AdminCount -eq 1} | Select-Object DistinguishedName

Well what exactly is AdminCount?

AdminCount: Indicates that a given object has had its ACLs changed to a more secure value by the system because it was a member of one of the administrative groups.

Further reading and comments on forums I found that if an account was ever in a domain administrative group the AdminCount is set to 1 in the attributes of the account.  Even after an account is removed from one of these groups the AdminCount is not set back to 0 but left at 1.  You can try setting it to 0 but if the account is still in one of those groups it’ll be reset back to 1 by the PDC every hour.

I then stumbled on a comment in a forum stating if an account has AdminCount = 1 then AD stops it from inheriting permissions.  Wait what, I have that issue too!  It clicked then that the accounts that we continued to have issues with the password reset tool were these same accounts.  In the past for whatever reason they had been in a privileged account group and no longer belonged to it and this AdminCount was still set to 1.  I edited these accounts in the Active Directory Users and Computers mmc on the Attribute Editor tab and just set the value to 0.  As I mentioned above the account will return to this being set to 1 if it is still in privileged account groups.  I then went to the Security tab and Advanced and ensured the Include inheritable permissions from this object’s parent was checked.  Now these accounts no longer have issues with the password reset tools!