Monday, December 10, 2012

Installation 2nd OM12 Management Server Fails: OpsMgrSetupWizard.log Shows Entry ‘Error: :Error:AddPrivilegesToDataWarehouseAccount: DAS account is not specified’

In the Netherlands have a saying:
All credits for the tile go to

The saying is based on this fact: A pearl come to be because in the oyster shell a small particle (sand) is irritating the mussel. Therefore it puts a layer of material around it so it doesn’t irritate anymore, thus a pearl is created. Thus meaning, out of irritation many good things come to be…

When looking at my blog, I can say the same about it for many postings. Quite a few times I bumped into a situation which really looked straightforward to me at the beginning but after 30 minutes, everything is totally different and a seemingly easy procedure – like ABC – turns sour. Until now I cracked most of them and posted them on my blog for the community and as my ‘personal’ KB library.

This posting is no different. A seemingly easy procedure goes bad. Took me some hours to find the cause but I cracked it. There’s much to tell so let’s start.

The Deal
Adding a second OM12 Management Server to an existing OM12 Management Group since only one OM12 MS is in place which isn’t valid for any OM12 environment.

Next > Next > Finish? No! Next > Next > Roll back!
Of course I have everything in place and ready. A new VM, with enough storage, CPU and RAM. Added to AD and the proper permissions in place. All the information of the MG is at hand with also the OM12 service accounts. The prereqs on the OM12 MS to be are installed and functional.

So lets start! Next > Next > Next > ?!%$^@ > Rollback?!

But all the OM12 services started so KB2677070 isn’t at play here. Double checked it (presumptions are the mother of all…), but no way, that KB isn’t present on that server. And yes, the new server can connect to the OM12 SQL Server without any issue. And yes, the account which runs the install has all the required permissions. Is admin on the local server, has OM12 Admin permissions and SA permissions on the SQL Server instance. And no, the firewalls aren’t blocking anything here.

So time for a deeper dive.

The Cause
The installation logs had to be investigated. System Center Central has written a good posting about where to find them and their purpose. So in the folder %LocalAppData%\SCOM\Logs I opened log file OpsMgrSetupWizard.log and went through it, step by step.

After some time I found these entries which puzzled me:

  1. Error:    :Error:AddPrivilegesToDataWarehouseAccount: DAS account is not specified;
  2. Error:    :AddPrivilegesToDataWarehouseAccount: failed: Threw Exception.Type: System.ArgumentNullException, Exception Error Code: 0x80004003, Exception.Message: Value cannot be null.

And that’s correct. Simply because the installation GUI of OM12 when installing an additional OM12 MS doesn’t prompt for those credentials:

As you can see, no credentials are entered for the Data Warehouse accounts (Read/Write). So the installer passes an empty value for those accounts which SQL Server refuses, causing the installation of the OM12 MS to fail.

But WHY?
OK, now I have found the cause. But now the reason WHY. I have installed many new OM12 environments with many additional OM12 MS servers. And that went just fine. So what’s different here?

In this particular situation the SQL Server being used here runs many other SQL Server instances as well. One is dedicated to OM12. But this is a named instance with another port then the default one, 1433.

Somehow, somewhere when an additional OM12 MS server has to be installed and the OM12 databases reside on a named SQL Server instance NOT using port 1433, the OM12 installer has to pass the Data Warehouse credentials used by OM12. But the GUI installer doesn’t prompt for them so it’s passes a zero value instead!

Why doesn’t the GUI installer prompt for ALL OM12 Service Account credentials? Good question and beats me as well…

The Fix
Install the additional OM12 MS servers using an elevated cmd-prompt while running a silent install. But before you start read this posting of mine as well because otherwise it won’t work.

  1. Close all other installation screens opened by the Install GUI of OM12. Otherwise the new installation will fail as well;
  2. Empty the folder %LocalAppData%\SCOM\Logs. Two reasons: we don’t want to be remembered by our failures and secondly we want clean log files;
  3. Copy the contents of the installation media of OM12 to the local server for instance C:\Install\OM12;
  4. Create the syntax for the Setup.exe file you’re going to need later on. Syntax is this:
    setup.exe /silent /install /components: OMServer /ManagementGroupName: XYZ /SqlServerInstance: SQLSERVER\INSTANCE /SqlInstancePort: 12345 /DatabaseName: OperationsManager /DWSqlServerInstance: SQLSERVER\INSTANCE /DWSqlInstancePort: 12345 /DWDatabaseName: OperationsManagerDW /ActionAccountUser: DOMAIN\SCOMACTION /ActionAccountPassword: PASSWORD /DASAccountUser: DOMAIN\SCOMSDK / DASAccountPassword: PASSWORD /DataReaderUser: DOMAIN\SCOMDWREADER /DataReaderPassword: PASSWORD /DataWriterUser: DOMAIN\SCOMDWWRITER /DataWriterPassword: PASSWORD /EnableErrorReporting: Never /SendCEIPReports: 0 /UseMicrosoftUpdate: 0
  5. Replace all values in blue with your values and copy everything into a single line;
  6. Open an elevated cmd-prompt and go to the folder containing the installation media of OM12;
  7. Run the syntax you made based on the information as described in Steps 4 and 5;
  8. Because it’s a SILENT installation nothing will be shown like a GUI for instance;
  9. In Task Manager however you’ll see some instances of msiexec.exe taking place;
  10. Be patient, in my case it took less then 10 minutes for the additional OM12 MS server to install successfully;
  11. Signs of success:
    1. The OM12 Console shows in Administration > Management Servers the additional OM12 MS which becomes green and stays like that (not greyed out anymore for an endless period of time);
    2. On the additional OM12 MS server itself the OpsMgr event log is being filled and continues to grow with good healthy messages;
    3. On the additional OM12 MS server itself, the earlier mentioned msiexec.exe processes disappear and are ‘replaced’ by some MonitoringHost.exe processes, telling you the OM12 MS server has started monitoring itself.
  12. Now with the additional OM12 MS server in place it’s time to install the OM12 Console as well, we left that initially;
  13. Open Control Panel > Programs and Features > select System Center 2012 – Operations Manager > right click, select Uninstall/Change;
  14. In the screen which appears now select the option Add a feature > Next;
  15. Select Operations Console > Next;
  16. Follow the rest of the wizard and the OM12 Console will be installed within a few minutes;
  17. Close all screens and install now the same Update Rollup which is in place for the OM12 MG on the newest OM12 MS server.

Now all is well and OM12 has an additional OM12 MS server. Still puzzles me why the installation GUI of OM12 doesn’t prompt for ALL OM12 Service Accounts. Would have saved me a lot of time…


devi said...

Hi Marnix,

Your post is excellent and very helpful for us.

Did you write any post for complex upgrade (where scom 2007 MS RMS server is on windows 2003 R2 OS)

It would be helpful as its bit difficult to upgrade it.

Thank you

Marnix Wolf said...

Hi Devi.

Thanks for your positive feedback. For migrating from SCOM 2007 R2 to OM12 I have written a whole series of postings. However, it's based on Windows Server 2008 R2 SP1.

When you run Windows Server 2003 you first need to add additional SCOM R2 Management Servers to that MG based on Windows Server 2008 R2.

When those servers are running fine you can move the RMS role to such a server so you have a new RMS server in place. One by one you can phase out the MS servers running Windows Server 2003.

When that's done and all Gateway Servers (if any) are Windows Server 2008 R2 as well, you can start the upgrade, that is of course when SQL Server 2008 R2 is being used as well for SCOM R2.


Marnix Wolf said...

Hi Devi.

Another approach could be to skip an inplace upgrade and to start alongside with a new OM12 environment. Sometimes this approach is far less timeconsuming compared to inplace upgrades when Windows Server 2003 and SQL Server 2005 are at play.


Unknown said...

Marnix I think you need to add 1 more line to your command line.
ExceptEndUserLicenseAgreement: 1