Configuring apcupsd on Xenserver / CentOS

Start by enabling the appropriate repositories:

vi /etc/yum.repos.d/CentOS-Base.repo

Enable the repositories by changing:




Then install the epel-release and apcupsd packages:

yum install epel-release
yum install apcupsd

After installation, the configuration file for apcupsd will be located here: /etc/apcupsd/apcupsd.conf

If you need to configure apcupsd to listed on the network (i.e., if you’re using an APC ups with an APC Network Management Card), you must modify some iptables rules. To ensure that they do not get lost upon reboot, simply add them to /etc/sysconfig/iptables. Here are the rules you will need to add (assuming default network port 3052 for apcupsd — change if needed):

# apcupsd
-A RH-Firewall-1-INPUT -m state --state NEW -m tcp -p tcp --dport 3052 -j ACCEPT
-A RH-Firewall-1-INPUT -p udp -m udp --dport 3052 -j ACCEPT

… And:

-A RH-Firewall-1-INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

You will need to add them to separate locations; see the following screenshot:

Then restart iptables and apcupsd:

service iptables restart
service apcupsd restart

Make sure to configure apcupsd to start on boot:

chkconfig apcupsd on

Wait a second or two after restarting apcupsd and then run apcaccess. If you receive a status from the UPS, then you’re good to go:

Configuring SSL on SQL Server 2012

This is more painful than it should be, but here’s how it’s done.

Step #1: Generate a CSR

In order to get an SSL certificate, you’ll need a CSR. SQL Server is picky about this — the process for creating one differs slightly than it does when creating one for a webserver. The following steps apply to certificates signed by a CA as well as self-signed certificates.

Open the Microsoft Management Console by typing mmc.exe into either the Run or Search boxes found on the Start Menu.

Microsoft Management Console

Microsoft Management Console

Once opened, click on “File” then “Add/Remove Snap-in…”


Add the Certificates Snap-in


Be sure to add it under the Computer account


Local Computer

Then hit OK


Expand Certificates, right-click on Personal, select All Tasks, Advanced Operations then click on Create Custom Request…

Custom Request

Click Next


Select Proceed without enrollment policy and click Next

Proceed without enrollment policy

Select the highlighted options and click Next

Certificate Enrollment (request options)

Open the Properties dialog


Give your request a Friendly Name and a Description


On the Subject tab, in the Subject name section, you need a Common Name — this should be the FQDN of the server; in the Alternative name section, you need to provide a Type: DNS value for the bare hostname and one for the FQDN of the server. It’s also a good idea to provide a Type: IP address(v4) for each IP that belongs to the server.

Subject tab

On the Extensions tab, click the arrow in the Extended Key Usage box and add the Server Authentication option.

Extensions tab

On the Private Key tab, select the options highlighted below, and click OK, and then click Next.

Private Key tab

Save your CSR somewhere and then either sign it yourself or submit it to a CA.


Step #2: Import Your Certificate

Open the Certificates Snap-in just like you did in Step #1, then expand Certificates, right-click on Personal, select All Tasks, and then select Import…

Import Certificate

Click Next, click Browse, locate your certificate file in the Open dialog, and then click Next again:

Certificate Import Wizard

Certificate Import Wizard 2

Browse for the certificate

Certificate import wizard 3

Place all certificates in the Personal store … click Next and then click Finish (and then OK).

Personal Certificate Store

Completing the wizard


Step #3: Configure SQL Server To Use Your New Certificate

Open Sql Server Configuration Manager and restart the SQL Server service. Nothing crazy should happen… not yet.


Navigate to Protocols for INSTANCENAME, right click on it, and select Properties

Protocols for instancename

Select your certificate and then hit OK

Protocols for instancename 2

Restart the SQL Server service one more time… if it starts up successfully, then you’re done. If it doesn’t (which is highly likely) then continue reading.

Step #4: SQL Server service does not restart successfully

Check the event viewer. If you see the following event IDs: 17120, 17826, 17182, 17663 then the user account the service is running as probably cannot read the server’s private key:

TDSSNIClient initialization failed 'n stuff

First, who is running the service? Open the Sql Server Configuration Manager, locate the SQL Server service, right-click on it, and select Properties. Find the Account Name input box on the Log On tab and make a note of the account name:

SQL Server Properties

Then, re-open the Certificates Snap-in just like you did in Step #1, locate your certificate (Certificates (Local Computer) -> Personal -> Certificates), right-click on it, select All Tasks, then select Manage Private Keys:

Manage Private Keys

A familiar Permissions dialog will appear. Click Add…:

Permissions for private keys

Click the Locations… button and select the location where the account resides… most of the time this will be the local computer:



Add the account that the SQL Server service runs as. Sometimes for local accounts, it is necessary to type the entire account name into the box titled Enter the object names to select and then hit OK (i.e., do not use the Check Names button.)

Give this user Read access, and then hit OK.

Read access

The SQL Server service should restart successfully now.

Windows Event IDs 6, 13, 82, & 10028: Cleaning up after the removal of a server that was hosting the Active Directory Certificate Services (AD CS) role

This post assumes that only one server was hosting the AD CS role and no certificates issued by this server are currently in use. If you have certificates in use, then please see the links at the bottom of the page.

The following items appear in Event Viewer with the same (or very close) timestamp, and events #10028 & #13 reference a server that no longer exists (highlighted in green in the 2nd and 4th screenshots that follow):

Event ID #6

Event ID #13

Event ID #82

Event ID #10028

This can happen when a Domain Controller or other Windows server hosting the Active Directory Certificate Services (AD CS) role is removed from the domain improperly. Sometimes this is unavoidable, for example if a server crashes. The solution is to remove the nonexistent server via Active Directory Sites and Services.

Step #1: Open Active Directory Sites and Services and show the “Services Node”

Select the top-most node in the tree,  then click on 'View' and select 'Show Services Node'

Select the top-most node in the tree, then click on ‘View’ and select ‘Show Services Node’

Step #2: Delete the offending (non-existent) server from the AIA, Enrollment Services, Certification Authorities, and KRA nodes

Note: it is absolutely critical that you do not delete any entries for servers that currently exist on the network!

Remove the non-existent server from the AIA node

Delete the non-existent server from the Enrollment Services node

Delete the non-existent server from the Certificate Authorities node

Delete the non-existent server from the KRA node

Step #3: If no other AD CS servers exist on the network, then remove all Certificate Templates. If other AD CS servers exist, then skip this step.

Note: Seriously — do NOT do this part if any other AD CS servers exist on the network. You have been warned. If there are any other AD CS servers, they’ll show up when you remove the non-existent server in step #2.

Delete Certificate Templates

Step #4: Cleanup

Run the following commands from an elevated command prompt:

certutil -dcinfo deleteBad
gpupdate /force

Further Reading

How to Decommission a Windows Enterprise Certification Authority and How to Remove All Related Objects

How to decommission a Windows enterprise certification authority and how to remove all related objects from Windows Server 2003

MS16-072 Breaks Security Filtering on Group Policy Objects

This update makes permanent changes in the way Security Filtering on GPOs needs to be configured. First, read this. Pay close attention to this part:


All user Group Policy, including those that have been security filtered on user accounts or security groups, or both, may fail to apply on domain joined computers.


This issue may occur if the Group Policy Object is missing the Read permissions for the Authenticated Users group or if you are using security filtering and are missing Read permissions for the domain computers group.


To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:

  • Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
  • If you are using security filtering, add the Domain Computers group with read permission.

A note on that last item under Resolution in the quote above: You are technically always using Security Filtering on GPOs. By default, the Authenticated Users object is applied to the Security Filtering on every newly created GPO. If you are looking at a GPO in GPMC, and you notice that Security Filtering is blank, then that policy isn’t being applied to any users or computers. Due to the changes made by the update, the computer account always requires Read permission on the GPO — this is by design:

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the computer’s security context.

The bottom line is that you can grant Read permission to either the Domain Computers or Authenticated Users group under the delegation tab of the GPO, and that will fix the problem with the GPO not being applied. Neither of those groups need Apply permission unless they contain users or computers that are being targeted by the GPO, that aren’t already being targeted by Security Filtering.

When I first encountered this issue, I noticed quite a few recommendations to “just rollback the patch” — this is not the correct course of action! The trouble caused by MS16-072 was not the result of a bug or poorly tested code, it was intentional, so if you remove the patch, you risk making yourself vulnerable to whatever threat(s) that were severe enough to prompt Microsoft into making such a potentially disruptive change. Besides, the “fix” is easy.

How might this affect your processes? What does this mean from here on out?

For Security Filtering to work on GPOs, you can no longer simply remove the Authenticated Users group, and then add your targeted objects (Users, Computers, Groups). The Authenticated Users group now requires Read access to the policy 100% of the time, otherwise the policy will not apply.

Why would anyone remove Authenticated Users from Security Filtering to begin with? Because, that group includes any User or Computer account on the domain, so let’s say you wanted a GPO to a subset of Users or Computers in an OU. In the past you would remove Authenticated Users from Security Filtering, create a new Security Group, add your desired Users or Computers to that group, then add that group to Security Filtering and link that GPO to proper OU. This is a convenient way to exercise precise control over GPOs.

Note, this update does not permanently take away this precision, it just means that if you had policies where the Authenticated Users group was removed, you need to add it back with Read access via the Delegation tab in Group Policy Management:

Add authenticated users back to GPO

But my GPO only targets a tiny subset of Users — I don’t wanna grant Read permission to the Authenticated Users or Domain Computers groups!

Ugh. Fine. The following will work but I don’t recommend it. If you recall from earlier, after this update User GPOs are retrieved via the Computer security context, so the Computer account of the computer that the user is logging into needs Read access to the GPO. Warning: this might will be hard to maintain in larger environments with lots of GPOs:

  1. Create a Security Group containing the Computers that are being used by the Users who require the settings contained by your GPO. For example, if your GPO targets user1, user2, and user3; and those users use computerA, computerB, and computerC respectively, create a Security Group that contains those computer objects.
  2. Grant Read permission on the GPO to that Security Group via the Delegation tab. If you don’t want to use a Security Group, then grant read access to the computer (if “computers” then you *really* should be using a group), directly.
  3. Apply Security Filtering to the users as you normally would.

Further Reading:

Locating the original MSI for software deployed via Group Policy

Click here for a scenario where you might need to do this.

Step #1: We need to find the GUID of the original MSI.

We can find this information in the registry of any machine that has the software installed. The information we need will be in one of two places, depending on the architecture of the package in question. If the architecture was x86 (32 bit), we will need to start here:


If the architecture was AMD64 (x64, or 64 bit) then we need to start here:


Simply navigate to either of the two aforementioned keys, select the Uninstall key and hit CTRL+F. In the window that appears, type a fragment of what you’re searching for (hint: use any part of the package’s name — e.g., “Box Sync”, “Google Apps”, “Lastpass”, etc. that shows up when you view the package from within Programs and Features) and then hit Find Next:

Searching the registry

For example, if you were looking for the GUID of the x64 Box Sync MSI and you searched “Box Sync”, you might see something like this, found under the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall key:

Or, if you were looking for the GUID of the x86 Google Apps Sync MSI, and you searched for “Google Apps Sync” it will be found under the HKLM\SOFTWARE\Wow6432Node\Microsoft\CurrentVersion\Uninstall key:

Success! We have found the _other_ package

The GUID has been highlighted in each of the previous screenshots — in the Box Sync example, the GUID is: {4E456910-7D68-4AD5-8A4A-CBD4A4635D0E}; in the Google Apps Sync example, the GUID is {091C294E-F243-432C-93E1-DEC4C2B9635B}. Copy it to notepad or the clipboard because you’ll be needing it soon.

Step #2: Use the GUID from the previous step to locate the key that contains the path to the MSI.

Now that you’ve found the GUID of the package you’re looking for, navigate to:


… and use the search function to search for the GUID:

Searching the registry... again.

You might have to hit F3 a few times, but eventually, you’ll find something similar to the following two examples — the info we need can be in either of the following REG_SZ keys: LocalPackage or ManagedLocalPackage:

Finally found the LocalPackage value

The path to the original MSI will be in either the LocalPackage or ManagedLocalPackage REG_SZ values. With any luck, the file will still exist in that location.

You might be wondering why I didn’t tell you to navigate to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer first, and search for the text — “Box Sync”, “Google Apps Sync”, etc. — but instead, I told you to find the GUID of the package that appears in the Uninstall key, then navigate to the Installer key and search for the GUID. Even with the extra step, finding the key that contains the LocalPackage or the ManagedLocalPackage REG_SZ entry goes faster if you know the GUID.