Nice to have it!! And welcome back!! Hope the new arrivals are doing well !

Hi Kevin, great article as always. I was following your steps in our SCOM environment, everything worked great but I have a question about the SQL scripts. I have already applied UR1 to this environment and there was a "update_rollup_mom_db.sql" script in "C:\Program Files\Microsoft System Center 2012 R2\Operations Manager\Server\SQL Script for Update Rollups" directory, which I executed during UR1 deployment.. After UR2 installation, that script seems not to have changed, the "last access" date property of the file show the day when I applied UR1, and the script has a creation date of "1/13/2014". The new "UR_Datawarehouse" script and the MPs in "Management Packs for Update Rollups" (also there were MPs here from UR1 and all of them seems updated) have all last access date of today.

Is there any way to confirm if this SQL script is the UR2 updated version? If not, is there a manual way to get the script without reinstalling the update? Thanks.

Kevin,
thanks for the information provided in your article. I used it to deploy this update to our SCOM environment.

Keep up the good work.

Kind regards

So what is the newest agent version? All my agents are version 7.1.10184.0 and I don't see anything change when I repair the agents. Also don't see them show up in Pending management.

Welcome back Kevin.

This might be a stupid question but is it worth waiting for UR3. I did the update in a test environment and the upgrade just smelt bad. The warning for the line ending with the DW SQL script and agents failing to update even after indicating the process completed after the agent approval.

I did as you mentioned and repaired the agents but am still deciding if I should wait till UR3 for my production environment. Hopefully UR3 the agent update issues are sorted and the process is a little more polished.

This is the first UR I have done and was a bit disappointed that I had to go digging to see if the update completed successfully for both the agent and the management servers.

Thanks,

Mike

You can check your agent version/patch from Powershell:

$agents = get-scomagent
$value = $agents[0].HostedHealthService.GetMonitoringProperties() | ? {$_.Name -eq “PatchList”}
$agents | select version, Name, PrimaryManagementServerName, ManuallyInstalled, @{Label=”PatchList”; Expression={$_.hostedhealthservice.getmonitoringpropertyvalue($value)}} | sort primarymanagementservername, manuallyinstalled, version | ft -autosize

If the PatchList value is empty, then you don't have the latest UR update on the agent.

Thx again Kevin.

Just updated the Prod environment (after running Windows Update and rebooting) and the agents came up as UR2 automagically (except for 3 servers).
In Test, which I did a couple of weeks ago, they had to be updated as per the blog post.
Go figure....
JB

FYI - There is also another issue that we have run into. The issue is centered around the # of State tables that have been created to hold the aggregated data and the SQL Log file size. In our case we had 455 State Hourly tables and our log file was able to grow to 100GBs. To attack this issue we first increase the SQL log to grow without restriction. (Note: We had several TBs of free space on the server to be able to do this) After the upgrade there is an expensive SQL query that re-indexes all the State Houly and Daily tables. If you have a large number of aggregated tables the SQL Script will timeout with the default value on the OperationsManagerDW as the query is written to proceed through ALL of the tables associated with Hourly State data. I believe the default timeout is 3 hours. During this expensive query there is a schema lock on the OperationsManagerDW preventing the management servers from writing data to it. The fix is to increase the SQL Query Timeout via a registry key on each of the Management Servers and restart the services. (reg add "HKLM\SOFTWARE\Microsoft\Microsoft Operations Manager\3.0\Data Warehouse" /v "Deployment Command Timeout Seconds" /t REG_DWORD /d 43200 /f) Roughly 15 minutes after the start of the Management Services, the SQL script will run. Allow it to finish. In our case it took just over 4 1/2 hours to complete and the SQL log file grew to 375GBs!! Once complete the Schema Lock lifts allowing data to be written and Dataset Maintenance Aggregation functions to complete. We experienced this on several OpsMgr Environments within our infrastructure. So I know some other people probably have run into the same issue so I thought I would share. :-)

Hi Kevin,

Just wondering about the additional fixes listed in KB: http://support.microsoft.com/kb/2929891:

Enable the web console fixes
Fix for the data warehouse BULK insert commands timeouts.

These were not listed in your step by step. Should these only be applied in certain circumstances?

Thanks,