Kevin Holman's System Center Blog

Posts in this blog are provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified in the Terms of UseAre you interested in having a dedicated engineer that will be your Mic

OpsMgr 2007 R2 CU3 rollup hotfix ships – and my experience installing it

OpsMgr 2007 R2 CU3 rollup hotfix ships – and my experience installing it

  • Comments 84
  • Likes

****NOTE OpsMgr 2007 R2 CU5 is now shipped and this is an old article.

http://blogs.technet.com/b/kevinholman/archive/2011/08/03/opsmgr-2007-r2-cu5-rollup-hotfix-ships-and-my-experience-installing-it.aspx

 

image

 

 

***Note:  I recommend reading this article all the way through…. things didn’t go exactly as I’d expected, and there are some very critical order-of-operations steps to be aware of.  There is a known issue where the SDK or Config service will not restart during the update, and cause the failure to roll back.  Steps to correct this are covered in the known issues of the KB article, and below in my troubleshooting section.  Make sure you read both sections before you begin.

***Caution:

There is a known issue documented in the KB article where applying this CU3 (or CU4) on existing OpsMgr agents can cause an unexpected restart of several non-OpsMgr services. This is caused by the Windows Installer RestartManager trying to suppress a reboot as we attempt to update a locked file. This can potentially cause application outages as the services for other Microsoft core OS components and some 3rd party application services might be restarted. This only affects agents running Windows 2008 and Windows 2008 R2. For this reason, you should consider skipping this update and waiting for CU5. Or, consider applying this update ONLY to your OpsMgr server roles, and rejecting any agent updates until the next CU. Here is the actual text from the KB:

  • Restart of non-Operations Manager services
    In certain cases, non-Operations Manager services may be restarted when the Operations Manager agent is updated. This issue only affects computers that are running Windows Server 2008 or Windows Server 2008 R2. We recommend that you update agents at a time when a service restart or a server restart is acceptable. Or, only update agents that are experiencing one or more of the agent-related issues that are mentioned in the list of resolved issues. This issue will be addressed in an upcoming cumulative update.

Make sure you see the other known issues and troubleshooting section both in the KB and below at the bottom of this article.

 

Get it from the download Center:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9f1e1154-52ae-42df-aeea-b3ee83247e6a&displaylang=en

The KB article describing the fixes, changes, and instructions:

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

 

 

The release notes in the KB article above cover the fixes that are included.  I have seen many of these issues manifested in the field, so I do recommend this update.  I have added it to my Recommended Hotfix page.

 

Here are the high level fixes:

  • Feature Addition: Azure Application Monitoring
  • Feature Addition: Parameter Extraction in Web Application Synthetic Transactions
  • Multi-selection in the alert view is not maintained during a view refresh
  • Upgrading MPs that include new properties may not recreate views correctly
  • The Operations Manager Console stops working when a high number of instances of State Views / Alert Views are left open for extended durations
  • The Operations Manager Console stops working when creating an override on the cluster resource group monitor
  • When using a remote console the notification wizards does not work in certain situations
  • The SDK Services stops working due to an unhandled exception, and the operations console becomes unresponsive
  • The SDK service may stop working due to an arithmetic overflow error in very rare circumstances
  • The notification scheduler does not compensate correctly for different time zones
  • Alerts using the “Specific Time Period” criteria are not included during automatic alert view refresh
  • Generic performance reports consume a large amount of temporary database space and can fail for Windows Server 2003 Computer Groups
  • SCOM 2007 SP1 Reports do not run after a shared Data Warehouse is upgraded to SCOM 2007 R2
  • Monitoringhost.exe does not work reliably on Windows 2003 SP2 X64 Domain Controllers
  • The total transaction response performance counter in URL monitoring is not accurate
  • MPs with empty knowledge elements cannot be imported in Operations Manager 2007 R2
  • Language packs authored for a previous version of an MP cannot be imported once an updated MP is released
  • Language Pack import fails if the MP contains strings which are not contained in the English Management Pack
  • When Agentless Exception Monitoring (AEM) is set up to use SharePoint, reports from Watson are blocked
  • Some ACS reports do not work as expected with Windows Server 2008
  • ACS forwarders with 15 character names in workgroups are unable to communicate with the ACS collector

 

 

 

Let’s Roll:

 

So – first – I download it.  The hotfix is about 1.2GB in size.  Yes, gigabytes.

Now – before your heart rate starts rising…. understand… this update is the first CU which combines the Cross Plat CU with the OpsMgr CU.  Aligning these is a very good thing – but it ends up increasing the size of the initial download.  No worries though – I will demonstrate later how to only have to copy specific files to lessen the impact of distributing this update to all your management servers and gateways, if copying a 1.2GB file around is a problem for you.

 

Next step – READ the documentation… understand all the steps required, and formulate the plan.

 

 

I build my deployment plan based on the release notes in the KB article.  My high level plan looks something like this:

  1. Backup the Operations and Warehouse databases, and all unsealed MP’s.
  2. Apply the hotfix to the RMS
  3. Run the SQL script(s) update against the OpsDB AND Warehouse DB.
  4. Import the updated management packs provided.
  5. Apply the hotfix to all secondary Management Servers.
  6. Apply the hotfix to my Gateway Servers.
  7. Apply the hotfix to my agents by approving them from pending
  8. Apply the hotfix my dedicated consoles (Terminal servers, desktop machines, etc…)
  9. Apply the hotfix to my Web Console server
  10. Apply the hotfix to my Audit collection servers
  11. Update manually installed agents…. well, manually.

Ok – looks like 11 easy steps.  This order is not set in stone – it is a recommendation based on logical order, from the release notes.  For instance – if you wanted to update ALL your infrastructure before touching any agent updates – that probably makes more sense and would be fine.

****Requirement – as a required practice for a major update/hotfix, you should log on to your OpsMgr role servers using a domain user account that meets the following requirements:

  • OpsMgr administrator role
  • Member of the Local Administrators group on all OpsMgr role servers (RMS, MS, GW, Reporting)
  • SA (SysAdmin) privileges on the SQL server instances hosting the Operations DB and the Warehouse DB.

These rights (especially the user account having SA priv on the DB instances) are often overlooked.  These are the same rights required to install OpsMgr, and must be granted to apply major hotfixes and upgrades (like RTM>SP1, SP1>R2, etc…)  Most of the time the issue I run into is that the OpsMgr admin logs on with his account which is an OpsMgr Administrator role on the OpsMgr servers, but his DBA’s do not allow him to have SA priv over the DB instances.  This must be granted temporarily to his user account while performing the updates, then can be removed, just like for the initial installation of OpsMgr as documented HERE.  At NO time do your service accounts for MSAA or SDK need SA (SysAdmin) priv to the DB instances…. unless you decide to log in as those accounts to perform an update (which I do not recommend).

 

Ok, Lets get started.

 

1.  I run a fresh backup on my OpsDB and Warehouse DB’s – just in case something goes really wrong.  Since I haven’t grabbed my RMS encryption key in a long while – I go ahead and make a backup of that too, just to make sure I have it somewhere.

I also will take a backup of all my unsealed MP’s.  This is good because there can be an issue with notifications, and having a fresh backup of the notifications MP is helpful.  You can do the backup in PowerShell, here is an example which will backup all unsealed MP’s to a folder C:\mpbackup: 

Get-ManagementPack | where {$_.Sealed -eq $false} | export-managementpack -path C:\MPBackup

We need to do this just in case we require restoring the environment for any reason.

 

 

2.  Apply the hotfix to the RMS.

Tip:  Here is a tip that I have seen increase the success rate:  Reboot your RMS/RMS nodes before starting the update.  This will free up any locked processes or WMI processes that are no longer working, and reduce the chances of a timeout for a service stopping, file getting updated, etc.

 

****Note: If applying this update to a RMS cluster – FIRST see:  How to apply a SCOM hotfix to a clustered RMS

****Note: – many people struggle with OpsMgr hotfixes – for failing to follow instructions.  When applying an OpsMgr hotfix – you need to copy the downloaded MSI file (such as SystemCenterOperationsManager2007-R2CU3-KB2251525-X86-X64-IA64-ENU.MSI) to EACH and EVERY Management server and Gateway.  You need to INSTALL this hotfix installer utility to EACH Management Server and Gateway.  Don’t try and just copy the update MSP files.  This wont work and you will fail to update some components.  Common complaints are that the agents never go into pending actions, or the agent update files never get copied over to the \AgentManagement folders.  In almost ALL cases, people were taking a shortcut and making assumptions.  Don’t.  Copy the 1.2GB file to each machine, then install the hotfix utility, then run the hotfix from the splash screen that comes up, immediately after installing the downloaded MSI.

 

Since my RMS is running Server 2008 – I need to open an elevated command prompt to install any SCOM hotfixes. That is just how it is.  So I launch that – and call the MSI I downloaded (SystemCenterOperationsManager2007-R2CU3-KB2251525-X86-X64-IA64-ENU.MSI).  This will install the Hotfix Utility to the default location. 

Tip: (This part may take a LONG TIME to complete if calling the 1.2GB file on a system will limited memory resources.  This is because it must consume 1.2GB of RAM to open the file, temporarily.  For production systems meeting the minimum supported 4GB, this probably wont be much of an issue.  For virtualized labs and test environments where you are running very limited memory, you will see this process take a considerable amount of time.  On my 1GB memory virtualized management servers, it would not install.  I upped them to 2GB and they took about 10-20 minutes to open and run the setup program.  See section at the end of this article **Command line install** for ideas on how to mitigate this issue if affected)

Then – a splash screen comes up:

 

image

I choose Run Server Update, and rock and roll.

 

Setup Failed on my first try.

I went through the log at %temp% (which is C:\Users\kevinhol\AppData\Local\Temp on my system) and took a gander at KB2251525-x86_0.log.  I really couldn’t find easily why it failed.  I did see some issues in the application event log about a product connector failing to connect to the SDK, and a WMI process locking EventCommon.dll…..   I would bet the reason for the failure was the service not starting up in time.  See troubleshooting section below.

So – I go ahead and reboot my RMS, just to free up any locked processes, if that was the issue.

Try number 2 begins:

I kick off the install again FROM THE 1.2GB MSI.  Since this is installed already – I choose “repair” and eventually the splash screen comes up again.  I choose “Run Server Update”.  This time, I get a SUCCESS! 

But wait!  As soon as I click “Finish” on the success screen, ANOTHER setup starts rolling.  I think that’s really odd…. but I let it complete.  It is also a success.  I click Finish again…. but then ANOTHER setup kicks off.  This just doesn’t look right, so I click cancel.  Bad idea.

After digging through the logs – I realize – this is all by design.  There are truly three installs going on, from three different MSI’s – that are chained together.  This is because it is installing the core OpsMgr CU3 update, then the ENU localization files, then the SCX cross platform update.  I just screwed up the last install because I haven't seen this before, and assumed it was broken and in a loop.

So – to clean things up again – I reboot my RMS, again.

Try number 3 begins.

I kick off the install again FROM THE 1.2GB MSI.  Since this is installed already – I choose “repair” and eventually the splash screen comes up again.  I choose “Run Server Update”. 

This time, I get a success, three times, from all three installs.  Phew!

Lesson learned, be patient, and as long as you see a success, click finish, and keep going.

 

You could see this potentially three times:

image

 

Then I click finish on the last one, then wait around 30 seconds for any post install processes to complete, and then click “Exit” on the splash screen.

IF you ever get prompted for a REBOOT – ALWAYS choose NO.

image

Now – it is time to validate the update applied correctly.  I can see the following files got updated on the RMS in the standard install path:  \Program Files\System Center Operations Manager 2007\

image

**note – this isn't all the files included in the hotfix package, just a spot check to make sure they are getting updated. 

 

Next I check my \Agentmanagement folder.  This is the folder that any agents will get updates from.  I check the \x86, \AMD64, and \ia64 directories:

image

 

It is good – that our KB2251525 CU3 agent MSI’s got copied over.

In this CU3, we did not remove the previous CU1 (974144) and CU2 (979257) MSI files.  However, those files will be ignored on future agent updates, repairs, and push installs.  You don't need it.  The key thing to check here is that you DID get a KB2251525 agent msp file.

 

***NOTE – it is CRITICAL to perform the next step in this order.  The SQL scripts MUST be deployed at this time, immediately after installing the update on the RMS.  If you don’t, you will see multiple events on the RMS about errors from the SDK (26319) and DataAccessLayer (33333).  The RMS will not generate new config until these scripts are executed.  Your consoles might also show the following, until you run the SQL scripts:

image

 

 

 

3.  Time to run the SQL scripts.  There are 3 scripts, located on the RMS, in the \Program Files\System Center 2007 R2 Hotfix Utility\KB2251525\SQLUpdate\ folder:

  • DiscoveryEntitySprocs.sql
  • CU3_Database.sql
  • CU3_DataWarehouse.sql

Let’s start with DiscoveryEntitySprocs.sql

**Note – this is the EXACT same patch file that was included in CU1 and CU2 for R2.  If you are upgrading from CU1 > CU3, or CU2 > CU3, you can skip this step.  If you are upgrading from R2-RTM > CU3, then you need to run this step.  This is called out in the release notes.  If you aren't sure, RUN IT.  It will not hurt anything if it is executed again.

I simply need to open this file with SQL management studio – or edit it with notepad – copy the contents – and paste it in a query window that is connected to my Operations (OperationsManager) Database.  I paste the contents of the file in my query window, it takes about 10 seconds to complete, and returns “Command(s) completed successfully”.

Second – we will execute the CU3_Database.sql file.  Open a NEW query window, make sure it is connected to your Operations database, and execute.  This one takes a little longer, and will return a long string of output stating (nn row(s) affected) multiple times, upon success.

Last – we now need to connect to the Warehouse database instance, and open a new query window against the OperationsManagerDW database.  We will execute CU3_DataWarehouse.sql which will return “Command(s) completed successfully”.

 

DO NOT skip step number 3 above, and do not continue on until this is completed.

 

 

 

4.  Next up – import the MP updates.  That's easy enough.  They are located at \Program Files\System Center 2007 R2 Hotfix Utility\KB2251525\ManagementPacks\ and are named:

  • Microsoft.SystemCenter.DataWarehouse.Report.Library
  • Microsoft.SystemCenter.WebApplication.Library.mp
  • Microsoft.SystemCenter.WSManagement.Library.mp

These will upgrade existing MP’s in your environment.  They take a few minutes each to import.

 

 

5.  Time to apply the hotfix to my management servers.  I have 3 secondary MS servers, one is Windows 2008 and the other two are older, they are running Windows 2003.  So on the 2008 server I open an elevated command prompt to apply the hotfix utility MSI, and just run it directly on the older servers. 

Again – I MUST RUN SystemCenterOperationsManager2007-R2CU3-KB2251525-X86-X64-IA64-ENU.MSI on each Management server.  This installs the hotfix utility, which will then launch the splash screen.

Tip: (This part may take a LONG TIME to complete if calling the 1.2GB file on a system will limited memory resources.  This is because it must consume 1.2GB of RAM to open the file, temporarily.  For production systems meeting the minimum supported 4GB, this probably wont be much of an issue.  For virtualized labs and test environments where you are running very limited memory, you will see this process take a considerable amount of time.  On my 1GB memory virtualized management servers, it would not install.  I upped them to 2GB and they took about 10-20 minutes to open and run the setup program.  See section at the end of this article **Command line install** for ideas on how to mitigate this issue if affected)

Once the splash screen comes up I “Run Server Update”  These all install without issue.  I spot check the \AgentManagement directories and the DLL versions, and all look great.  REMEMBER – you can sure patch all your management servers at the same time, however, your agents WILL fail over during this time because we stop the MS HealthService during the update.  Keep this in mind.  It is best to update management servers one at a time, synchronously, to keep your agents from failing over to the RMS and overloading it, or causing massive Heartbeat failures because they have nowhere to report to.

Note:  You might see the following pop up after the last setup routine is complete.  Just ignore this for now and hit OK, and then we will need to reboot this server when we are finished.  This box says “Error” when there really isn't a problem – this is noted in the KB article as a known issue.

image

 

 

6.  I would patch my Gateway machines here.  I still don't have a GW in my lab, so I move on to the next step.  Remember to spot check your DLL and \AgentManagement directories.  Previous hotfixes did not copy the hotfix MSI to the \AgentManagement directories, and so you might have to do that manually.

 

 

7.  I check my pending actions view in the console – and sure enough – all the agents that are set to “Remotely Manageable = Yes” in the console show up here pending an agent update.  I approve all my agents (generally we recommend to patch no more than 200 agents at any given time.)

After the agents update – I need to do a quick spot check to see that they are patched and good – so I use the “Patchlist” column in the HealthService state view to see that.  For creating a “Patchlist” view – see LINK

image

 

The CU3 actually REPLACES any previous patches applied in the PatchList table – this is NICE.   Looks good.  (Note) I will have to formulate a plan to go and update my manually installed agents (Remotely Manageable = No)

Note: experienced 100% success rate on the agent updates…. however, some of my agents are still reporting both the CU2 and CU3 in patchlist.  I am investigating this as it should not be reporting this way.

 

 

8.  I have a few dedicated consoles which need updating.  One is a desktop machine and the other is my terminal server which multiple people use to connect to the management group.  So – I kick off the installer – and just choose “Run Server Update as well.  I do a spot check of the DLL files – and see the following was updated on the terminal server:

image

 

 

9.  Next up – Web Consoles.  I actually have two – and both are running on management servers, which I have already patched.  So – I will simply just go check their DLL files to ensure they got updated:

From:   \Program Files\System Center Operations Manager 2007\Web Console\bin

image

 

 

10.  I don't have ACS set up at the moment – but at this point if I did – I would go hit those Management servers that have already been patched – but this time run the update and choose to “Run ACS Server Update”

image

 

 

11.  Manually installed agents.  I have a fair bit of these… so I will do this manually, or set up a SCCM package to deploy them.  Most of the time you will have manually installed agents on servers behind firewalls, or when you use AD integration for agent assignment, or when you installed manually on DC’s, or as a troubleshooting step. 

 

Now – the update is complete.

image

The next step is to implement your test plan steps.  You should build a test plan for any time you make a change to your OpsMgr environment.  This might include scanning the event logs on the RMS and all MS for critical and warning events… looking for anything new, or serious.  Testing reporting is working, check the database for any unreasonable growth, run queries to see if anything looks bad from a most common alerts, events, perf, state perspective.  Run a perfmon – and ensure your baselines are steady – and nothing is different on the database, or RMS.  If you utilize any product connectors – make sure they are functioning.

The implementation of a solid test plan is very important to change management.  Please don't overlook this step.

 

 

 

*** Command line install option 

In some situations, you might want to perform a command line installation of the update on your RMS/management server.  Most of the time – I don’t recommend this, because you generally need the feedback if each part was successful or not.  However, there are situations where it is required. 

One example is for users who have issues with the 1.2GB MSI file, and getting the hotfix installer running, especially on limited memory systems.  For those, you can use a command line options which removes the issue.

The KB article has a section which documents how to set up the arguments correctly.  I used a variation of that, because I did NOT want /silent to be used… as I want to visibly see the feedback and interact with the installation.  Here is the command line I ran, for an US/English installation:

SetupUpdateOM.exe /x86msp:KB2251525-x86.msp /amd64msp:KB2251525-x64.msp /ia64msp:KB2251525-ia64.msp /x86locmsp:KB2251525-x86-ENU.msp /amd64locmsp:KB2251525-x64-ENU.msp /ia64locmsp:KB2251525-ia64-ENU.msp /Agent /noreboot

In order for this to work – you need to INSTALL the hotfix utility somewhere, then copy the ENTIRE FOLDER STRUCTURE starting with the KB2251525 folder and all folders below.  Here is an example copied to C:\temp\ directory:

image

Just remember – you cannot run just specific MSP files in these folders individually, there are post install processes that must be run, and should be called by the SetupUpdateOM.exe.  You also cannot just run SetupUpdateOM.exe by double-clicking it, or the post install processes wont run.  Use the default method of installing the original downloaded MSI file, OR use this command line option.

 

For additional command line options, including how to make a CU3 package smaller, and how to patch consoles, agents, etc…. see the following post:

http://blogs.technet.com/b/kevinholman/archive/2010/10/12/command-line-and-software-distribution-patching-scenarios-for-applying-an-opsmgr-cumulative-update.aspx

 

 

 

Troubleshooting/Common Issues:

 

1.  CU3 fails to apply.  The SDK service will not start after this, and CU3 fails on subsequent retries.  Emre Guclu of Microsoft PFE has come up with the following approach which has seen much success:  Using http://support.microsoft.com/kb/922918 set the ServicesPipeTimeout entry for all services to have 3 minutes (180000 milliseconds) and REBOOT the server.  Then try and apply CU3.  It will apply.  You likely will see a few warning messages about failure to start the OMCFG service – just click ok and the setup will continue.

2.  Agent patchlist information incomplete.  The agent Patchlist is showing CU3, but also CU2 or CU1 or nothing.  The localization ENU update is not showing in patchlist.  This appears to be related to the agents needing a reboot after having the first CU3 package installed.  Once they are rebooted, and a repair initiated, the patchlist column looks correct with the ENU (localized) information.

3.  26319 Error events on the RMS OperationsManager event log every 60 seconds: 

Event ID:      26319
Description:
An exception was thrown while processing SetupAlertsByCriteriaAndMonitoringClassReader for session id uuid:fd790420-2ace-4756-beba-242f49e9f838;id=27.
Exception Message: Object reference not set to an instance of an object.

This is caused by the SCVMM integration with OpsMgr, and an issue with CU3.  If you are impacted with this issue, please contact Microsoft support.

4.  Restart of non-Operations Manager services.  In certain cases, non-Operations Manager services may be restarted when the Operations Manager agent is updated. This issue only affects computers that are running Windows Server 2008 or Windows Server 2008 R2. We recommend that you update agents at a time when a service restart or a server restart is acceptable. Or, only update agents that are experiencing one or more of the agent-related issues that are mentioned in the list of resolved issues. This issue will be addressed in an upcoming cumulative update.

Comments
  • Hi Kevin,

    Thanks for another helpful guide. I deployed CU3 at the university earlier and had perfect success messages at every stage - none of the problems you appear to have had. Very strange stuff!

  • Hi Kevin,  

    Thanks for the another great guide.  When you push out the agents updates, what ports are being used?  Does it use the default 5723?  

  • Followed the steps, first install did not complete, SDK service never came back up.

    Hosed.

    Bummer!

  • Hi Kevin,

    did I read it correctly and do I need to upload 1.2GB (for a manual installation) data to update an agent only installation of typically 90MB??

  • @Jeremy - when you push agents - this is done over netbios/rpc, not 5723tcp.  

    @Ian - you are the second person reporting this.  Did you open a case?  I will be looking at that this morning.

    @Marcus - NO!  Sorry - the agent can be updated by simply grabbing the correct core msp and ENU msp files from the extracted directories.... for manual patching.  I will look into command lines for those.

  • Hi Kevin

    Thanks for your guide.

    May you tell me, what's the difference between KB2251525-xx-ENU-Agent.msp and  KB2251525-xx-Agent.msp. If I install it, there isch shown two fixes: "System Center Operations Manager 2007 R2 Cumulative Update 3 (KB2251525)" AND "ENU Components; System Center Operations Manager 2007 R2 Cumulative Update 3 (KB2251525)". We gonna deploy with SCCM and I need to know, witch files they have to package.

    Thanks a lot for your help.

  • @Marcel:

    The ENU package is the localization package - there will be different localized version if your environment is installed with some other version than US/English.

  • I am about to now. I'll let you guys know what we find.

    -Ian

  • @Ian Do you have a clusterd RMS? Did you pause the node during installation? Marcel

  • No clusterd RMS. 3 Servers, RMS, MS, and DB.

  • o.k. we had this problem during installation CU1. We didn't pause the inactive clusternode. Hope Kevin may help you asap. Good luck!

  • Ian - look at the troubleshooting steps - try increasing the timeout for services - reboot RMS - and then try CU3.

  • Kevin,

    This was a 2008 virtual server in a lab environment with only 3 gigs of ram. I followed the KB (support.microsoft.com/.../922918) article you mentioned above and it worked “with some trial and error”. It says to set it to 60,000, and I did with no luck :\

    I rebooted again after setting ServicesPipeTimeout to 90,000, It failed the first update but finished the second. Still the SDK was not coming up… I then changed it to 250,000 and rebooted again. Tried the patch again and presto, Completed Successfully. I plan to grant the Hyper-V virtual server 2 more gigs of ram and remove the ServicesPipeTimeout entry added to  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control.

    Thanks for the guidance :)

    -Ian

  • Hi Kevin,

    I had the same problem as Ian had with the SDK service not starting. I followed his instructions and all is well now. Yay!!!

    Thanks guys

    Nick

  • Guys - I added this to the troubleshooting section in this post.  You need to set it to 180000 for most cases.

    3.  CU3 fails to apply.  The SDK service will not start after this, and CU3 fails on subsequent retries.  This is being investigated.  Emre Guclu of Microsoft PFE has come up with the following approach which has seen some success:  Using support.microsoft.com/.../922918 set the ServicesPipeTimeout entry for all services to have 3 minutes (180000 milliseconds) and restart the server.  Then try and apply CU3.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
Search Blogs