So you need to update your Dell OpenManage Server Administrator’s SSL certificate it runs on because maybe Tenable sees an untrusted SSL cert or your organization requires everything to be signed by their servers. In the past there was a crazy set of command lines to run to make this happen but now you can just export a PFX file from Windows MMC and import it directly with the latest versions of OMSA! I know it works with OMSA 10 at least but unsure about later versions of OMSA 9.
Export a PFX
This will be a brief overview of the special settings needed and will assume you know how to use the mmc certificates plugin and how to request certificates within your organization. You’ll need a Computer certificate with the FQDN of your server that is running OMSA that allows exporting the private key.
Right click your certificate in the MMC -> All Tasks -> Export -> Yes, export the private key -> Choose PFX if it’s not auto chosen -> uncheck Include all certificates, uncheck Enable certificate privacy, check Export all extended privacy.
Then on the next page check Password -> enter a 20 character maximum password, set Encryption to TripleDES-SHA1
Save the PFX files and then transfer it someplace safe you can access from your computer to upload in the next step.
Import the PFX
Login to Dell OMSA -> Preferences in the top right -> General Settings on the far left -> X.509 Certificate in the center. Then click Import a PKCS#12 keystore -> Next and you’re finally at the import page. Select Choose FIle and browse for your PFX file and then enter your 20 character or lower password -> Import. The system will give you the option to restart the web interface which can take a minute or two then Ctrl-R the website to force a fresh check and the browser should now show a good certificate.
I didn’t think this worked at first because Dell OMSA would error saying it was an invalid PKCS#12 file or a bad password. Well it’s clearly not the password because I’m copy pasting it from a password manager into every field. So I went down a chase to turn it into a Java Keystore file because the Dell OMSA documentation states the file is a JKS. After going through all that it still didn’t work. Come to find out as you noticed above, the password was the issue. I noticed something after several attempts, the dots in the password field didn’t look as long as it should have. Come to find out the Dell OMSA password field only allows 20 characters to be entered and I was using a 30 character password! So frustrating! This is an old issue from older Java 8 where its keystore tool only supported maximum 20 characters but the new OMSA runs on Java 11 which doesn’t have this restriction.
So lets say you’re moving from Windows 2008 R2 IIS 7.5 to something newer and you have Certificate Trust List (CTL) you use for CAC authentication. You’re used to that CTL being passed down to the client to then filter the user certificates on their system to only be the ones available that you want them to be. You migrate to Windows 2019 with IIS 10 and instead of that nice filtered list you instead get ALL certificates on a user’s system instead.
So you run McAfee ENS + Windows 10 1903 + AMD GPUs well you’ll discover that in this scenario the video drivers and AMD control software fail to load on your systems resulting in the default video driver loading. This results in the loss of multiple monitors and enhanced graphics capabilities. We worked with McAfee on this with an official case and in the end they blamed AMD even though if you uninstalled McAfee ENS the AMD drivers began loading. The solution in the end was AMD updating their drivers to resolve something that was having issues with the McAfee ENS software. You need to be running AMD Radeon Adrenaline 19.9.2 or newer to resolve this issue.
If you disable Allow unlisted file name extensions in IIS using the Request Filtering module you’ve always had to then allow “.” (just a period by itself) in the File Name Extensions to then allow IIS to feed up the default document without it being in the URL. For example http://www.google.com versus http://www.google.com/index.htm which without the . added won’t work. In IIS 10 on a couple of websites we found they would throw 404.7 errors when this was configured even with the . in the allow list.
I noticed this for the first time on a Windows Server 2019 system when I was migrating websites from Windows Server 2008 R2 using Web Deploy 3.6 from Microsoft. I started loading websites to test them and was greeted by IIS Error 404.19 – Denied by filtering rule. If you hit refresh it might then load successfully and do so a couple of times then fail again with another 404.19 error. In IIS this is the website -> Request Filtering -> Rules area for a website.
Microsoft let us get soft for a while with WMI filtering. WIndows 2008, 2008 R2, 2012, and 2012 R2 were all WHERE Version like “6.%” in WMI filtering. Our WMI filters kept plodding along without anyone having to care. Then Windows 2016 hit and we had to start updating our filters for a new WHERE Version like “10.%” so we could target these new systems and so our filters would continue to work. Well now we have Windows Server 2019 which is also 10.0 version string so we can’t easily do like we did in the 2008-2012 era of 10.1, 10.2, etc. Now we have to care about WHERE Version like = “10.0.XYZ”…
We’ve been having a very odd issue with new Windows 2019 server running Hyper-V in that some of them will fail to enable Replication for VMs. You get to the very end and and click the last button to start and the Replica VM is created on the other system and all the place holder files exist but then it errors with an message about not being able to send the initial replica. We’ve tried all kinds of suggestions on the web related to ACLs and firewall configuration but none of them worked. I found a solution though. If you make a Checkpoint of the system having issues and then delete the Checkpoint after its completed you can now enable Replication. It seems the issue resides on the system where the VM currently lives and not the location it’s going to and forcing a Checkpoint corrects whatever is going wrong during Replication configuration.
We were working on migrating our Domain Controllers from Windows 2008 R2 to Windows 2019 and I got to the point where I was running the PowerShell “Test-ADDSDomainControllerInstallation -DomainName MyDomain.Name” command to test migration requirements. The process was kicking out an error for part of it with a context of Test.VerifyDcPromoCore.DCPromo.General.103 so I started the hunt for what that meant. Well both the Bings and Googs came back with no results at all for the exact search value. Plenty of other items with different numbers at the end but not specifically 103.
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. Continue reading “Convert MAK licensed Windows system back to KMS”→
You must be logged in to post a comment.