Wednesday, July 29, 2009

Blog moved

New URL:

http://greatit.wordpress.com/

Offline Address Book download error 0x80190197 Operation failed

Situation: Exchange 2007 SP1 + Outlook 2007. Offline Address book in public folders and on HTTP distribution point.

I recently noticed that my machine and others were no longer downloading the OAB. Outlook of course didn't notify me, we just noticed it because some new accounts were not showing up. When I did a manual download of the OAB, I get the pretty meaningless Error 0x80190197 The Operation Failed

The Exchange server itself looked fine, the OAB was being generated and replicated, no errors.

I did a quick network trace to check what Outlook is doing while downloading the OAB, and to my surprise I saw no traffic to the actual Exchange server hosting the OAB. I did notice much traffic to my proxy server however, which was suspicious since I was not doing anything but getting the OAB at this point.

I then checked my proxy settings in IE, and sure enough, the "Bypass proxy server for local addresses" was not configured properly. I added some internal IPs, addreses and the Exchange server, and I was able to download the OAB again.

Friday, July 10, 2009

Delegating permissions to write SPNs in Active Directory

A follow-up to the post below.

I tried delegating the ability to write SPNs (Service Prinicipal Names, used for Kerberos) to a non-Domain admin who did not have full control on the server objects. Since this is a really big organization I also did not want to grant him full control on those objects (Politics...)

I thought delegating this shouldn't be a big deal, so I gave his account the permission "Validated write to service principal name" and applied to all computer objects in the servers OUs.

Of course it doesn't work. Instead of "insufficient permissions" we now got the error 0x200b/8203 -> The attribute syntax speified to the directory service is invalid. when using SETSPN.

I checked Microsoft's documentation, and sure enough it says I only need "Validated write to service principal name". I used the network to see what it actually tries to write, and it only seems to be the SPN attribute.

I then assigned full control to the account, and then he was able to write the SPNs. Long story short, after some educated guessing it looks like he also needs the "write public information" permission.

error 0x20b5/8373 when registering a SPN

We recently delegated permissions to register SPNs to a network administrator. When he tried to register a SPN using setspn, he got this message:

error 0x20b5/8373 The name reference is invalid

We found the solution quickly: He was providing an invalid SPN (the error message could be a little clearer)...
Instead of doing HOST/Servername he had used HOST\Servername

To summarize: When you get this error, make your SPN is correct regarding syntax etc.

Wednesday, July 8, 2009

Custom Presence States for Office Communicator R2 2007

There's plenty of examples on how to create custom presence states in OCS 2007.
Check out this example.

If you want to do this in OCS 2007 R2 it is still possible using the same approach, but you cannot use a FILE location. It MUST be an HTTPS location.

Wednesday, June 3, 2009

Windows Time error event IDs 38, 24, 20

We recently upgraded a domain controller to Windows Server 2008. A couple of days after that the site administrators reported a problem with time synchronization on one of his servers. In fact it looked like the time was in sync, but we saw w32time errors and warnings in the system log.

Our first guess was of course that this is related to the DC upgrade so I started checking this machine. The server however was doing just fine, it was synchronizing with its time source and advertising as a time server.

Taking a closer look at the system it turned out that it was a virtual machine running on Hyper-V. We ended up disabling the Hyper-V integration for TimeSynchronization and the errors went away.

Wednesday, March 11, 2009

LDAP based discoveries with Powershell in Operations Manager 2007

Compared to MOM 2005 I was pretty disappointed with the discovery wizard for new agents in the SCOM 2007 console. In my opinion it's not flexible enough for large deployments - but that's what Powershell is for, right :)

We keep strict naming conventions in our Active Directory so it is pretty easy for me to create LDAP queries that return only the servers I want to monitor in SCOM. Let's say I want all Exchange Servers and all of their names end with "EXCHSRV". To get started in the Ops Manager shell we have to create an LDAP query object:

$myldap = new-ldapquerydiscoverycriteria -domain MYDOMAIN -ldapquery "(&(objectClass=Computer)(name=*EXCHSRV))"

We then create a Windows discovery object (my Exchange servers run all on Windows....):

$windiscovery = new-windowsdiscoveryconfiguration -ldapquery $myldap

To start the actual discovery and store the result in another object:

$discovery_results = start-discovery -managementserver (get-managementserver) -windowsdiscoveryconfiguration $windiscovery

If necessary you can look at the $discovery_results object to see which machines were discovered. They will be stored in the CustomMonitoringObjects property.

If you are ready to deploy the agents to the discovered machines you can use this command:

foreach ($server in $discovery_results.CustomMonitoringObjects) {
install-agent -AgentManagedComputer $server -confirm
}

This will loop through each discovered machine and try to install the agent. By using the -confirm parameter we tell the script to ask before doing anything. This can be omitted of course, however I'd be careful unless you are sure your LDAP query is correct and matches only desired machines.

Of course you can use a similar approach to query for any given LDAP property. I put this in a script to scan the domain on a regular basis for new machines that might still be missing a OpsMgr agent.