Things were initially going well but he explained that he ran into a rather strange issue just after migrating the first batch of agents across to just talk to his live 2012 infrastructure, what made it stranger was these had been talking to his test infrastructure (dual homed) fine for quite a while.
When he moved them across, shortly after, the System Center Data Access service stopped and refused to start.
No matter what he tried it wouldn't work and he had to fall back to restoring a backup.
This left him a little hesitant about the stability of his live environment and whether something wasn't quite right underneath it all somewhere, but it seemed to be fine after the restore so he thought he'd see how it went.
Well the same problem reared it's ugly head again the other day so he did some more digging.
Eventually he stumbled across this post from Travis Wright explaining an issue seen in Service Manager.
http://blogs.technet.com/b/servicemanager/archive/2011/10/04/system-center-data-access-service-start-up-failure-due-to-sql-configuration-change.aspx
Since Service Manager and Operations Manager share the same code base and the problem described is essentially a SQL problem anyway he took a look to see if it was indeed the same issue affecting him, turns out it was!
It finally turned out to be something one of the developers were doing with custom reports and scheduling that was adding a local SQL account to the security roles as DBOwner (Dev to be taken outside and shot...)
So in summary, if you're using SCOM and your System Center Data Access Service refuses to start and you're seeing event log errors such as:
- 26325 Authorization store exception
- 26339 Exception thrown while initializing the service container
- 26380 Unhandled Exception
Good find Rob, now get your blog back online and start sharing things like this again ;)
No comments:
Post a Comment