SQL Server Alias for x64 Systems

Found a weird quirk with SQL aliases today. We were trying to create an alias for our SCCM DB to ease some migration stuff we're working on plus as a best practice going forward. Turns out that if you're running a 64bit the clconfg.exe utility must have the alias in its 32 and 64 bit version.

Start > Run > "cliconfg.exe" does NOT open the SysWOW64 version of the utility by default. However, that is exactly what is required for the DB connection to establish. What was so weird is that it requires both versions. As soon as I removed the 32bit alias my connection would fail (more specifically the SCCM installer to update the SQL settings).

So what I learned was you have to run both of these and put in the same settings for each. This is just the experience I had so I'm open to feedback on the "why" behind it.

C:\Windows\SysWOW64\cliconfg.exe

C:\Windows\System32\cliconfg.exe

Add TCP/IP Alias

• Server Alias: something like "SCCM-DB" 
• Server Name: <SQL Server Name>\<Instance> (instance only if applicable) 

REFERENCES

The alias thing was just an oddity we found while trying to accomplish the following (though he wasn't using aliases).

http://blog.rohrauer.at/how-to-move-a-sccm-system-center-configuration-manager-2007-database-to-another-host/

**UPDATE**

I would recommend using DNS aliases for this. Just add a CNAME for the DB. This way if an installer asks for a server you can put in something like above "DB-SCCM". You may still want to use SQL aliases to get it to a specific instance or something. So far just using the DNS CNAME has worked really well for us. Used it for SCCM, WSUS, SharePoint, and SCOM. Makes moving the DB super easy later.

-Shep

Citrix Licensing - v11.9 - Update Bugs

Had some issues this week updating our Citrix licensing server. A five minute task took me two hours. We had a simple renewal of our subscription advantage (SA). I took downloaded the new .lic file from mycitrix and imported through the Vendor Daemon options. That seemed to work fine. I selected the "Overwrite" option. However, it didn't overwrite. It was still showing the old license plus the new ones. Also, the numbers were now incorrect for both.

I got Citrix on the line and was informed "yea that happens sometimes, overwrite doesn't always work as intended. Fortunately, the fix was simple.

1. Backup your .lic file(s)
2. Delete the .lic from the MyFiles folder (default location for Citrix licensing)
3. Restart the Citrix Licensing Windows service.
4. Import the new license again
5. Reread license file under Vendor Daemon options

After restarting the service with no licenses you'll see nothing in the licensing console. Then you can import into a clean slate. We did this midday with no impact to our farm (to be expected since the servers run on cache for a period of time when no license server is found).

Side Note: We restarted the Windows Service because the "Stop" option under Vendor Daemon does nothing. Known, documented bug in v11.9 of the licening console.

-Shep

Microsoft FEP 2010 Deployment Health Alert

I ran into this issue almost immediately after importing the management pack for Forefront Endpoint Protection 2010. Our FEP 2010 Deployment State was showing Critical. It turns out that the Microsoft documentation is incomplete on the subject. The issue we encountered was with the DB perms.

We needed to grant the account that FEP runs under some limited perms to the following databases. For us that was the Network Service acct.

• Master
• public
• RSExecRole
• msdb
• public
• RSExecRole
• FEPDB_<site code>
• db_AgentPermissions
• db_SCCMDataExtractors
• public
• FEPDW_<site code>
• db_AgentPermissions
• db_OlapPermissions
• db_ServicePermissions
• public

This is just what the Microsoft support tech set the perms to. I can't vouch for all of it being completely necessary but it started working immediately for us.

I started with this which I would definitely recommend going through. Be sure to review that everything is done for pre-reqs before anything else. Perms, management packs, etc.

http://technet.microsoft.com/en-us/library/gg508724.aspx


One thing to note is that the FEP Date Warehouse state is really sort of redundant because the SQL pack would monitor it to (a recommended pre-req for FEP MP). Even so, I hate errors and wanted it fixed!

-Shep

OpsMgr Active Directory fSMORoleOwner Alerts

OK. To start off, I’d like to point out that this is WAY less complicated than it sounds. The actual change takes about 5 minutes. It was the research and planning that took ALL of the time. Anyway, here goes!

THE PROBLEM

We recently identified a problem through System Center Operations Manager 2007 R2 with our Active Directory environment. A while back we had to forcibly demote our primary domain controller for DNS, DHCP, and the fSMORoleOwner. As a result, when the new DCs were put in there were still traces of the old configuration.

This was the error that allowed us to identify the problem.

AD Replication Partner Op Master Consistency : The script 'AD Replication Partner Op Master Consistency' failed to execute the following LDAP query: '<LDAP://DC3.MYDOMAIN.com/CN=Configuration,DC=MYDOMAIN,DC=com>;(&(objectClass=crossRefContainer)(fSMORoleOwner=*));fSMORoleOwner;Subtree'. The error returned was 'The server is not operational.' (0x80040E37)

I found that the fSMORoleOwner in ForestDNSZones and DomainDNSZones were both different and neither were correct. It should have been set to DC1 but the ForestDNSZone showed DC2 (a current DC) and the DomainDNSZone showed OLD-DC1.

CHECKING YOUR SYSTEM

You’ll need the following to check this out. Add these to ADSI Edit…

1.       Configuration

2.       DC=DomainDNSZones,DC=MyDOMAIN,DC=COM

3.       DC=ForestDNSZones,DC= MyDOMAIN,DC=COM

After scouring the forums I found that the fix was to copy the settings from the distinguishedName attribute under Configuration in ADSI Edit for the correct fSMORoleOwner. I took that information and updated the owner attribute under DomainDNSZones and ForestDNSZones.

THE GOTCHAS

A couple of gotchas along the way…

1.      This must be done under on the actual infrastructure master.

2.      Formatting. This really is common sense but it got me. I read in several places to copy the distinguished name. However, that value is in a different format than the fSMORoleOwner property. Just be sure to grab a copy of the existing fSMORoleOwner value for two reasons.

a.       Copy the proper formatting

b.      Revert if there was some weird reason you’d need to (unlikely).

3.      For some reason this kept throwing me off. CN=Infrastructure is at the root of the Domain/ForestDNSZones. If you just expandeded that container you wouldn’t see it.

distingushedName example

CN= DC1,CN=Servers,CN=Site1,CN=Sites,CN=Configuration, DC=MyDOMAIN,DC=com

fSMORoleOwner example

CN=NTDS Settings,CN=DC1,CN=Servers,CN=Site1,CN=Sites,CN=Configuration,DC=MyDOMAIN,DC=com

So back to the forums for one last double check.

http://social.technet.microsoft.com/Forums/sr-Latn-CS/winserverDS/thread/95c78db6-f53a-48c7-84c9-3c57cd683e4c

1.      Some people pointed to Anti-virus issues. In our environment this was NOT the issue. OpsMgr was right on the money.

2.      One thing that I had questioned but wasn’t necessary for us was a metadata cleanup. I would say it is definitely something anyone should do in this situation. However, we found that the metadata was actually removed properly. I point this out so people don’t assume the cleanup will fix the issue. It’s just good advice and best practice.

3.      There is a script “fixfsmo.vbs” that will do the same. I didn’t use it because it was just as easy to update it manually. The script is pretty basic. It checks the current, checks what it should be, updates if it doesn’t match.

CHECKLIST

Phase 1 - fSMO cleanup

1.       Perform AD Backup (system state and system drive) NTBACKUP.exe

2.       Turn off extra domain controller (if you have one available)

a.       This was a great idea my supervisor had. If anything when wrong we could make it look like this DC had the latest version of settings and replicate that back to the others.

b.      Update fSMORoleOwner in forestDNSZones and domainDNSZones

3.       TEST!

a.       Confirm logging in on all DCs works, VPN, etc. etc.

b.      If no issues, power on the extra DC.

4.       Validate replication using repadmin /replsum (I had to force the replication to the DC that was powered off)

5.       Confirm that OpsMgr errors go away

Phase 2 - DC metadata cleanup

1. Repeat backup process
2. Run cleanup utility

Scripted Method– pretty cool

http://gallery.technet.microsoft.com/d31f091f-2642-4ede-9f97-0e1cc4d577f3

Manual Method from command prompt

Ntdsutil.exe

Ntdsutil.exe: metadata cleanup

metadata cleanup: remove selected server <server name>

3. Repeat testing

RESOURCES

Here were some other valuable resources I referenced along the way

http://forums.techarena.in/active-directory/1143475.htm

http://social.technet.microsoft.com/Forums/sr-Latn-CS/winserverDS/thread/0b956901-930c-4fe7-80ad-939de1f61b48

http://technet.microsoft.com/en-us/library/bb727048.aspx

http://technet.microsoft.com/en-us/library/cc731035%28WS.10%29.aspx

http://support.microsoft.com/kb/949257

Hopefully someone finds this helpful. I know it was painful for me assembling all of this information, planning testing. In the end there were no reboots required, no downtime, nothing like that. But there’s something to be said for the peace of mind after having all of the necessary information.

-Shep