Uninstalling/removing SP3/SP2 for MOSS/SharePoint 2007 RRS feed

  • Question

  • Hi,

    To best of my knowledge, I understand that Service Packs for MOSS 2007, Say, SP3 cannot be uninstalled. Can anyone please share your thoughts on the same.

    Is it possible to Remove installed Service Packs from SharePoint servers?

    Naveed.DG SharePoint Administrator

    Friday, March 16, 2012 7:55 PM

All replies

  • I hate to say it, but your understanding is correct. There really is not an easy way to uninstall a SharePoint service pack or cumulative update package for SharePoint, and its never something I would recommend doing in a production environment. SharePoint updates are really a one-way street: you can only go forward with them and there's no way to uninstall, roll back, or remove them once you've started the installation process.

    The reason for this is that there are two components to the update process: 1) updating the SharePoint bits installed on each SharePoint server and 2) updating the schemas and configuration of the farm's databases in its SQL Server instances. If you uninstall the bits from your SharePoint servers, those databases are still going to be functioning at the level of the applied CU and will not work with your servers.


    MCITP and MCTS: SharePoint, Virtualization, Project Server 2007
    My books on Amazon: The SharePoint 2010 Disaster Recovery Guide and The SharePoint 2007 Disaster Recovery Guide.
    My blog: My Central Admin.

    Friday, March 16, 2012 8:10 PM
  • John,

    I appreciate your valuable answer. Could you please suggest a better Disaster recovery plan in case after installing SP3 farm breaks down. To be precise, we tested SP3 on our Test environment and entire Farm went down. We did enough troubleshooting and were able to fix one by one and finally Configuration Wizard ran successfully, but took lots of time.

    We cannot afford the same on PRODUCTION.

    So what would be the better Disaster Recovery plan ?

    Naveed.DG SharePoint Administrator

    Friday, March 16, 2012 8:21 PM
  • Hey Naveed,

    I'd be very interested to know what the issues were you ran into and how you got around them / fixed them. Do you have them logged anywhere? Was the problem due to customizations to the site that had been done or more simply bugs in the SP3 installation process itself?

    Best regards,


    Thursday, May 31, 2012 8:37 AM
  • Hi Ruwan,

    Most of the errors/issues we faced were primarily because of heavy customizations used in our sharepoint sites. Issue were not at all because of any bugs in SP3, as in an out of box environment SP3 installation went very smooth.

    The exact issues we faced were;

    1. SharePoint configuration wizard would fail on step 8/9. By that time schema version for Content Databases used to get upgraded, but not for Configuration database and sometimes not for Central Admin content database.
    2. As a result of above, sites didnt open. Error used read like "Database schema version mismatch....."
    3. Since we were on Test environment (copy of Production) we went into database schema and changed back the schema version and found sites started working fine. But NOT the real solution.
    4. Likewise, many other application related errors were fixed and I am so sorry we have not documented it, but I can recongnise issues and solve them, if I come across them once again :) Phew!!

    So my question was is there a way to uninstall installed service packs ..and answer is NO!...so we should plan for a better disaster recovery process to be in place before we attempt SP installation in PROD environments.

    Naveed.DG SharePoint Administrator "Vote As Helpful" If it helps!!

    Thursday, May 31, 2012 1:23 PM
  • Hi Ruwan,

    This is exactly what we are also trying to figure out. While installing the sp3 in the production server and in the middle if we got stuck up with any error then how to rollback to the old version or what is the better disaster recovery process to be followed while installing the SP's in share point server.

    Did you get any answer for this? if so can you share with us. Thanks.

    badri prasad, Software Engineer

    Wednesday, August 29, 2012 3:47 AM
  • Your rollback options should a service pack or cumulative update fail are:

      • Restore to a backup made before upgrading. The first step of any upgrade should be to perform a full backup of the entire farm
      • Revert to a snapshot made before upgrading. This only works if the entire farm consists of virtual servers. It's usually faster, easier, and less error prone than a full backup/restore though can only be used if all the servers in the farm are virtual servers. In theory you could clone ("ghost") the servers before installing the update if your servers are physical.

    Notice that in both cases you need to make a backup or snapshot before running the installation. If you didn't perform this step you have no roll-back options.

    Jason Warren
    Infrastructure Architect

    Wednesday, August 29, 2012 4:31 AM
  • Using snapshots of multi-server virtualized farms is not a supported scenario as it will lead to inconsistencies on rollback (if rolled back) due to timer job resolution.  Restore from backup is your only option for "reverting" any SharePoint update.


    Wednesday, August 29, 2012 5:01 AM
  • Using snapshots of multi-server virtualized farms is not a supported scenario as it will lead to inconsistencies on rollback (if rolled back) due to timer job resolution.  Restore from backup is your only option for "reverting" any SharePoint update.

    This seems like one of those things that if you bungle up your farm, MS Support may choose not to help you, perhaps I should not have been as cavalier with my suggestion.

    From Virtual machine guidance (SharePoint Server 2010):

    Using snapshots

    Snapshots provide a very useful tool for capturing the current state of a running, paused, or stopped virtual machine. The snapshot feature enables you to quickly and easily revert to a previous virtual machine configuration. This capability is particularly well-suited to a development or test environment.

    As a best practice, we recommend that you do not use the snapshot feature on virtual machines in a production environment for the following reasons:

    • Clock synchronization: When you take a snapshot of a running virtual machine, there is latency between the time the snapshot is started and the time the snapshot is finished. This latency affects SharePoint Server timer jobs and, as a result, time synchronization between farm servers.

      If you choose to take a snapshot of a virtual machine, shut down the machine to allow running jobs to finish before taking the snapshot. We recommend that you closely monitor the virtual machine and other farm servers after the virtual machine is restarted to ensure that there are no time synchronization issues.

    • Performance: When you create a snapshot for a virtual machine you have, in effect, created a differencing disk. There is a continuous exchange of configuration data between the virtual machine and the snapshot, which affects performance.

    If you shut the servers down and perform the snapshot while they are off (and again, I mean every server in the farm, including SQL Servers) you should not experience the timer job clock-sync issue.

    Backup and restore is the best supported option (it's why I listed it first). Use snapshots if you're comfortable and understand the risks.

    Jason Warren
    Infrastructure Architect

    Wednesday, August 29, 2012 1:16 PM
  • i am getting the below error while upgrading the SP3 service pack..

    it's failing at step 8 with the below error.

    Cannot open database "WSS_Search_CACGVUBOBD102_New" requested by the login. The login failed.

    This database does not exist on my database server but still it is looking for this DB. Please suggest.

    • Edited by pearl_mukesh Thursday, September 5, 2013 12:44 PM
    Thursday, September 5, 2013 12:44 PM
  • Thanks Jason. We are planning to attempt applying MOSS 2007 SP3 on Production environment which consists all Physical servers. As a back up, we are planning the following things

    1) Full Back up all the SharePoint DB's from Production

    2) Full back up all the WFE's and APP servers ( backing up all the drives in each server)

    Rollback Option

    Regarding rollback approach, i would like to check on the following approaches

    1) In the event of triggering rollback, can we simply restore all the SharePoint DB back up's taken prior applying SP3 keeping the state on the WFE's and APP server as -is. Will this bring back the application to working state?

    2) As a second option, can we restore all the drive back up taken on all the WFE's and APP server on the respective servers besides restoring all the SharePoint DB's prior applying SP3. Will this bring back the environment back to SP2? 

    Please let us know. Thank You!

    Friday, June 19, 2015 11:47 AM