Creating an ADMX/ADML Central Store

As time goes on, Microsoft releases new features to be controlled with Group Policy.  You add these new GPO’s by downloading .admx and .adml files from Microsoft and adding them to your Domain Controller.  You do this by first creating a Central Store for your admx/adml files, assuming that you do not already have one in place.  Note that this process is unnecessary if you have a single Domain Controller as they are all pulled from from the local PolicyDefinitions folder.  When you have multiple Domain Controllers in your environment you want them to share the same PolicyDefinitions so there are not any discrepancies.

To do this, login to your Primary Domain Controller (or the DC with the highest version of Windows Server) and navigate to C:\Windows.  You will find a directory name PolicyDefinitions here.  Copy that directory and paste it in the following directory C:\Windows\SYSVOL\domain\Policies.  This pasted PolicyDefinitions folder will now be the central store that all DC’s will grab its admx/adml files from (aka a central storage location for all GPOs for your domain).  After this you simply download the admx/adml files that you wish to add from Microsoft and paste them into your newly pasted PolicyDefinitions folder and the corresponding language folder(s).  For example, if I wanted to add GPO’s for controlling Microsoft Office 2016, I could do so by downloading the admx/adml files from here and then adding them to the appropriate folders.  Easy peasy!

Kaspersky Security Center Failing “Backup of Administration Server data” task

Today I realized that the backups for my Kaspersky Security Center (Version: 10.4.343) were not completing successfully.  They were failing with the following error:

“Unknown error: System error 0x5 (Access is denied.)”

A little bit of background, I have one master Kaspersky Security Center administration server and a few slave servers off of that (for different customers).  Each are running on Server 2012R2 and have their DB’s on separate 2012R2 boxes using SQL 2012.   I also use a domain service account to run the Administration Service on the servers hosting the Security Center as I have had some issues with the built in account it generates during installation in the past.

Honestly, it is kind of silly that this took me about an hour to figure out but I’m going to blame that on my caffeine not kicking in fast enough.  At first I figured the issue was that I did not explicitly delegate permissions to the service account running that admin service to the file share that I was saving the backup to.  Strike one, no dice.   After some deliberating with myself and those in the room I finally woke up and realized it’s a backup of the database.  The database, as I said earlier, is on a separate box with an installation of SQL 2012.  SQL uses a built in account to perform all of its actions named NT Service\MSSQLSERVER.  Naturally I cannot grant permissions to this account on my remote share since it is a local account, and granting permissions to the computer account didn’t work unfortunately (strike two).  After all this, the solution was right in front of my face.  The share the backup is saving to needs to be on the same box as the DB.  Once I reconfigured to meet those requirements backups started flowing like Niagra Falls.

All in all, I had a pretty bad brain fart when setting up my backup tasks.  Oops!

Managing WinRM Trusted Hosts

Below is a quick cheat sheet for managing your WinRM Trusted Hosts with PowerShell:

 

Adding and Removing Active Directory OU’s with PowerShell

 

Windows 7 Not Connecting to Wired Network Prior to Login

This is an issue that historically I have found often with wireless network connections, but very rarely with wired connections. This has always been easily resolved by simply pushing the pretty standard GPO found below:

Computer Configuration\Policies\Administrative Templates\System\Logon

Always wait for the network at computer startup and logon

Naturally I stumbled upon a case where this was not the case. I pushed the GPO and even changed the local GPO to no success (the main indicator being an error in the event log saying it couldn’t contact DC during logon). One Google search later I found the answer (here). Set the following local GPO:

Computer Configuration\Administrative Templates\System\Group Policy

Startup policy processing wait time = 120

You can play with the wait time numbers, but 2 minutes worked for me.  As one would expect this does slow the boot time significantly (by two minutes, who would have thought), but it will get you up and running.

The New User Script to Rule Them All

I have gone through many versions of this user creation script as time has gone by, and so far this particular one is really hitting the mark.  It doesn’t do everything, but it takes care of 98% of everything so that I don’t need to rely on my help desk always setting things up appropriately (yay for scripting making everything consistent!!).  Anywho, this version of the script will do the following with PowerShell: Create the AD account with all the properties I need and a random password, set the account to require password change, populate proxy address attribute on the account, create the user accounts “home” folder (doc redirect), share and set both ntfs and share permissions on the folder, create a DFS link for the “home” folder,  and add the account to necessary groups.

Phew that’s a mouthful.  Before I drop the code, there is one disclaimer.  The script will prompt for credentials at the beginning.  These credentials MUST be able to create/edit AD accounts, have administrator access to file server, and be delegated in DFS.  Also, PS-Remoting must be available on the File Server/Server that hosts ADFS as I invoke commands remotely, and these two servers need to be in your local machines WinRM Trusted Hosts list.

You can add more to the multi-array and reference it as needed (for example group names), this is just a more basic example of how to get things done.

Enjoy!