This one was a new one… and a bugger to track down!  While renaming domain computers, several of the rename operations would encounter an error during the rename process of

The following error occurred attempting to rename the computer to [New Name]:
The directory service is busy.

Well, if you have SQLExpress or SQLServer installed, the error may be leading you down the wrong path.  In our particular case, the error was a security error related to SQLExpress / SQLServer SPNs (Service Principal Name).  Basically, the rename operation could not rename the SPNs.

How to identify a potential SPN issues

1. Open a CMD prompt as an administrator
2. enter the command:
   setspn –L [Computer Name]
3. Check for *any* registered SPN which is in the format of
   MSSQLSvc/[Computer Name]:[Instance Name]

In short, if you have *any* SPN which starts with MSSQLSvc, you will not be able to rename your computer!

How to fix SPN issues

1. For *each* identified SPN above, you must delete the SPN using the following command:
   setspn –d [SPN Name] [ComputerName]
   Important: You must use the full SPN name as identified via the setspn –L command.  These will be in the format of MSSQLSvc/Computer.domain.tld:instance

That is it!  You can now rename your computer!

It seems when we setup a new WordPress site on IIS (for whatever reason) the question always arises: “What is the directory and file security again?”.  We haven’t pulled the actual metrics, but we suspect this is one of the top 100 most asked questions of all times.

To help our own rather leaky memories, we are putting together this blog entry on our own internal best practices.  Hopefully it helps you as well!

Our Best Practices Overview

• Modify level security is only allowed on .\[WordPress]\wp-content\uploads
• All other directories are read only
  Why?  This helps prevents malware from infecting your site.
• During updates (plugin or WordPress itself), the entire WordPress site is set for Modify permissions.
  Important:  Manual updates (XCOPY) are safer but not necessarily easier.  That being said, if you are already on the box setting permissions, you are already in position for an XCOPY update!

Initial Setup Details

1. At the WordPress root directory (.\[WordPress])

1. Remove all inheritance from the parent objects
   Why?  This prevents the parent directory objects from changing your security without you knowing about it!
2. Replace all child object permissions with inheritable permissions from your WordPress root directory
   Why?  This guarantees that all WordPress directories get your explicit permissions!
3. Grant the user IUSR the following permissions: Read & Execute, List folder contents, Read
4. Grant the group IIS_IUSRS the following permissions: Read & Execute, List folder contents, Read
5. Grant the group Administrators the following permissions: Full control
6. Recommended:  Remove the group Users (I.E. grant the Users group no rights to the WordPress directory)

1. Remove all inheritance from the parent objects
   Why?  This configures your upload directory for specific permissions to allow publishing of content!
2. Replace all child object permissions with inheritable permissions from your \uploads directory
3. Grant the user IUSR the following permissions: Modify, Read & Execute, List folder contents, Read, Write
4. Grant the group IIS_IUSRS the following permissions: Read & Execute, List folder contents, Read
5. Grant the group Administrators the following permissions: Full control
6. Recommended:  Remove the group Users (I.E. grant the Users group no rights to the \uploads directory)

Update Time Details
When it becomes time to update your WordPress site, perform the following steps:

1. At the WordPress root directory (.\[WordPress])

1. Grant the user IUSR the following permissions: Modify
   Why?  Permissions inheritance will automatically set all WordPress directories to allow modification by the IUSR account.  This will allow updates to be performed

Important: Be sure to remove both the Modify and Write permissions from IUSR when you are done with your updates!

We here at ArmgaSys have started to see a high incident rate of User Profile loading failures.  These failures have different symptoms, but exactly the same root cause.

Symptom #1:  The never ending logon
This symptom is classically described as:

1. You sit down in front of a PC you have logged into every day since you started work
2. You enter your user name and password
3. You are greeted by the “Welcome” screen
4. You watch the “Welcome” screen spinner for hours…. and hours… and hours….

Symptom #2:  New profiles can’t be created
This symptom is classically described as:

1. You have called your client services folks over because of the never ending logon
2. Your client service guy (or gal) logs onto your PC with their administrative account
3. They receive the always entertaining “The User Profile Service service failed the logon.  User profile cannot be loaded”
   

Symptom #3: The event log
Upon reviewing the PC’s event log (which any good Client Service team will do) reveals:

Event 1509, User Profile General
WIndows cannot copy file \Users\Default\AppData\Local\…\sqm-data[SEQUENCE].sql to location [A profile location goes here]
This error may be caused by network problems or insufficient security rights.

DETAIL – Access is denied

Root Cause
The Software Quality Metrics software instrumentation system flubbed up a file in your user’s profiles.
We see this a lot in Visual Studio installs (VS2010 – VS 2013) but have noticed an increase in other Microsoft products.

How to fix
It is simple!  Find and delete the SQM files listed in the event log

-OR- (The more draconian approach)

1. Navigate to C:\Users\Default\AppData\Local\
2. Search for *.SQM (all SQM files)
3. Delete them!

Good luck!