It’s been a long time since I ran through setting up a central policy definitiosn store. In that time, you’ve probably had to copy ADMX (and ADML) files into your central store manually. Microsoft updates typically DO download updates but puts them (usually) in C:\Windows\PolicyDefinitions, There’s probably a sensible reason for that.
When someone cleverer than I has scripted this, and included support not just for Windows, but for;
Adobe Acrobat
Adobe Reader
Base Image Script Framework (BIS-F)
Citrix Workspace App
FSLogix
Google Chrome
Microsoft Desktop Optimization Pack
Microsoft Edge (Chromium)
Microsoft Office
Microsoft OneDrive (installed or Evergreen)
Microsoft Windows 10 (1903/1909/2004/20H2/21H1/21H2/22H2)
Microsoft Windows 11 (21H2/22H2)
Mozilla Firefox
Zoom Desktop Client
Solution: Auto Update ADMX
Execute the following command.
[box]
Install-Script -Name EvergreenADMX
[/box]
Answer any questions with a ‘Y’.
Now to test the script you can simply run Evergreenadmx.ps1 and it should run though manually. Once you’ve ascertained that it runs without error you can use the following syntax to update you central store*
Here I’m creating a Scheduled task (If you feeling lazy simply import this one) Give it a sensible name > I would set it to run monthly Unless you are downloading browser and application ADMX files also > I’ve scheduled it for the second Wednesday of the month (See what I did there?)
If you attempt to connect to and send mail via command line to your Exchange Server, you may see the following error after you end the data section of the operation.
451 4.7.0 Temporary server error. Please try again later. PRX5
Solution 451 4.7.1 Error
Log into Exchange Amin Center > Mail Flow > Receive Connectors > Default Frontend {Server-Name} > Edit > Scope > Select the IPV4 entry (Either Remove it and ad a new one or edit it)
Specify the IP address you want to use.
So, it should look like this > Save > Exit Exchange Management.
Open Notepad (Note: you need to run as administrator). Navigate to C:\Windows 32\Drivers\Etc locate the hosts file (If you can’t see it change the option to “All Files“
At the bottom of the file enter the IP hostname and FQDN of the server then save and exit.
Then restart the Exchange Transport Service.
Related Articles, References, Credits, or External Links
We used to have Microsoft LAPS, now we have Windows LAPS!LAPS is a solution that lets’ you store admin passwords ‘elsewhere‘ be that in your local Active Directory or Azure Active Directory*. Unlike previously, where you had to deploy/install client software, it’s now built into Windows from the following versions.
Windows 11 22H2 – April 11 2023 Update
Windows 11 21H2 – April 11 2023 Update
Windows 10 – April 11 2023 Update
Windows Server 2022 – April 11 2023 Update
Windows Server 2019 – April 11 2023 Update
*Note: Is in the pipeline at time of writing traditional (on-premises) AD only is supported.
The premise is that instead of having a single (easily compromised) local admin password (or DSRM password on a DC) for your assets you can have a different password (that can be controlled with a complexity policy) for each client/server and that password is stored securely in Active Directory, (as an attribute of the computer object).
Backup to Azure AD
Backup to Local (On-Premises) AD
Azure AD Joined
Yes
No
Local (On-Premises) Joined
No
Yes
Hybrid Joined
Yes (if not backed up to on-premises AD)
Yes (if not backed up to Azure AD)
Workplace Joined
No
No
Solution: Windows LAPS
Firstly, FULLY update all the domain controllers in the domain.
On a DC you can load the LAPS module and look at the commandlets.
[box]
ipmo LAPS
gcm -Module
[/box]
From these commandlets the first one we need to use is Update-LapsAdSchema, this will extend the active directory schema and add the LAPS attributes to the computer objects.
[box]
Update-LapsAdSchema
[/box]
It will ask you con conform you can watch each step by pressing Y – or if you’re lazy (like me) simply press A {Enter}.
You can’t really see what it is doing, but if you’re interested, you can run the same command again with a -verbose switch on it to see exactly what going on.
OK, but what has that done? Well as I said above, the computer objects have been extended and they now have ALL have the following attributes.
Note: Yes, there’s now a LAPS tab also, but there won’t be anything in there yet.
The next commandlet we need, Set-LapsADComputerSelfPermission, will grant the computer object the rights to manage its own LAPS password, You can set this on the root of the domain if you wish. Here I have all my computer objects in an OU called PNL so I’m applying that right at the TOP LEVEL OU, and it will apply to all children OUs.
Create a new GPO (or edit an existing one) that links to the OU where your COMPUTER objects live. (remember if managing DSRM passwords you will also need to link the policy to the Domain Controllers OU also).
Edit the Policy and navigate to;
[box]
Computer configuration > Policies > Administrative Templates > System > LAPS
[/box]
Note: If you have a LAPS folder directly under Administrative Templates, that’s for the older Microsoft LAPS settings!
Policies to edit;
Enable Password Backup for DSRM accounts : Enable
Name of administrator account to manage : Enable >laps.admin
Note: If you already have a local admin account, built into you master computer image for example, you can use that account instead.
Further policy to edit;
Password settings : Enable > (I accept the defaults)
The screen shot below shows how the policy should look before you exit the group policy editor.
Windows LAPS Local Admin
Here I’ve manually created the local user, you can either roll this out by script, GPO, or building the account into the your default image for OS deployment.
Retrieving Windows LAPS Passwords
Below you can see we can retrieve both a local Windows LAPS password for a client, or a DSRM password for a domain controller.
Simply click Show password and Copy password, and the password will be on the clipboard (as shown).
To get the password via PowerShell use the Get-LapsADPassword commandlet.
[box]
Get-LapsADPassword "PNL-Win11" -AsPlainText
[/box]
Troubleshooting Windows LAPS
The update also allows you to view LAPS event logs in the Event Viewer, like so.
Interoperability Microsoft LAPS and Window LAPS
If you have the older Microsoft LAPS running (i.e. Your end clients have the LAPS client software being deployed to them, then when the Apr 23 LAPS update is deployed to them and used, BOTH Systems may stop working. To fix this you need to disable Legacy LAPS by setting the following registry key on your clients.
[box]
HKLM > Software > Microsoft > Windows > CurrentVersion > LAPS > Config
[/box]
Create a new 32 bit DWORD value called BackupDirectory and set its value to 0 (zero).
Once the Azure AD element is fully released and supported, I’ll loop back and include that also.
Related Articles, References, Credits, or External Links
The administrative template that you get with Win11 is somewhat out of date, so if you want to manage OneDrive with domain group policy your options are limited, if only there was a newer administrative template!
Well, there is, and it gets updated and sent to you quite regularly. Microsoft just do a good job of hiding it.
Solution OneDrive GPO
Depending on your deployment the files you need can be in different locations, the biggest challenge is finding them. execute the following PowerShell to locate them.
As you can (above) see mine are in my user profile. The folder that they are in will also give you the build number, so you can check occasionally for updates (that will get pulled down when your OneDrive client gets updated).
Go to that directory and you will find the ADMX and ADML files.
Note: For anyone who is not English speaking, there may be a different ADML file in the locale folders you can see above.
Copy the OneDrive.admx file into your PolicyDefinitions folder (if unsure of the path, see below. obviously substitute your own domain name and here I’m on a domain controller so the SYSVOL volume on my local drive).
Now change to the INPUT LOCALE folder (in my case en-US) and copy the OneDrive.adml file into that folder.
Then when you are in the Group Policy Management Editor you will see the updated OneDrive options.
If you have a vanilla install of Exchange, it will clean up the UnifiedContent folder on a four hourly schedule. the problem occurs if you have moved your Exchanges ‘Queue” directory. This will also relocate the UnifiedContent folder, but then Exchange, will still try (and fail) to tidy it up in the original location, (because it’s not there anymore!)
Typically, you will see your UnifiedContent folder growing slowly like so.
Note: You can tell by the folder path (above), that the queue directory is ‘non-standard’ i.e. I’ve placed the mail queue on its own partition, (Drive letter Q:). COPY THE PATH TO UNIFIEDCONTENT FOLDER TO THE CLIPBOARD.
Solution: UnifiedContent Growing
Locate your Antimalware.xml file, as you can see in my example (below) This lives in the Bin subfolder in the Exchange deployment folder, like the quote folder, mines in a non-standard folder also (I like to be different). If you have a standard deployment the file is usually located in.
Search withing the file for the following text string.
[box]
TransportRoles\data\Temp\UnifiedContent
[/box]
You will see that this is the location that the Microsoft Exchange Health Monitor Service expects the UnifiedContent folder to be at, and yours will probably be pointing to,
Change the ENTIRE path (from the semi-colon to the quotes) and replace it with the ACTUAL path to your UnifiedContent folder, (you copied earlier). Then save the file and exit Notepad.
Before the change will take place, you need to restart the Microsoft Exchange Health Manager service.
[box]
Restart-Service MSExchangeHM
[/box]
Now nothing will happen for four hours (you can manually delete some of the older files if you are having capacity issues!) After four hours all the older files should have been purged, and this process will continue to prevent the problem from re-occurring again.
Related Articles, References, Credits, or External Links