Portal upgrade

Martin_Strbavy

Hi,
I am planning to upgrade SSP (analyst) portal to latest version. We are having 4 web servers which are load balanced. Can someone guide me which server should be upgraded first? I guess that CacheBuilder should be upgraded first, and then all others. Is there during running setup some difference if it runs on cachebuilder server or others?

What is fastest recovery method for SSP? just revert VM clone and DB? Is there something specific/special to think about before upgrade?

My High level steps are: 

1. Make backup of SCSM/SCSM DWH/SSP
2. Update Cireson Licensing apps - https://support.cireson.com/KnowledgeBase/View/1224#/
3. Upgrade Asset Management - https://support.cireson.com/KnowledgeBase/View/59#/ or detailed steps for install https://support.cireson.com/KnowledgeBase/View/75#/
4. Upgrade SSP - https://support.cireson.com/KnowledgeBase/View/1349#/

Thanks
Martin

Adam_Dzyacky

My suggestion would be:

1. Stop IIS across all of your servers. This will ensure it's impossible someone is using the portal during the upgrade
2. Take a backup of your ServiceManagement DB. You can optionally take backups of your other DBs, but the Cireson installer does not perform any modification to these core elements of System Center
3. Upgrade the one running CacheBuilder first. I tend to select "Don't start Cachebuilder" so I have the opportunity to re-adjust how often items (e.g. Service Catalog, Configuration Items, etc.) sync and turn my logging level up to "ALL". Then enable the CacheBuilder service and start it. Once this gets kicked off...
4. Upgrade the remaining IIS servers. Since they aren't doing anything more than deploying a website I tend to run task in parallel. Then go in and change things such as ensuring the AppPool doesn't time out and initializes after a restart
5. At this point - CacheBuilder and your IIS farm is running and you've upgraded to the latest portal

Now in the event something fails, a customization doesn't work, or anything is out of the ordinary I would:

1. Stop IIS across all of the servers. Stop Cachebuilder
2. Perform a DB restore of ServiceManagement pre-upgrade
3. Re-run the installer for the Portal for a previous version

But snapshotting VMs and reverting back also accomplishes the same thing. You're simple just going back to a previous point in time (e.g. pre-upgrade) as though the upgrade never happened.

Now as far as anything special to think about pre-upgrade is if a development environment is available, test deploy there first. Not only can you practice the upgrade yourself, you can also test any internal customizations you may have made.

Shane_White

Hi @Martin_Strbavy,

To answer your first question about the CacheBuilder, the one running it should be updated first although it wouldn't make a massive difference if you didn't! However the CacheBuilder Service should be running on only 1 server and should be disabled on the other 3 servers.

Your high level steps you have listed look very good and great for best practice if you are doing backups/snapshots or any Servers or Databases beforehand!

Thanks,
Shane.

Adam_Dzyacky

My suggestion would be:

1. Stop IIS across all of your servers. This will ensure it's impossible someone is using the portal during the upgrade
2. Take a backup of your ServiceManagement DB. You can optionally take backups of your other DBs, but the Cireson installer does not perform any modification to these core elements of System Center
3. Upgrade the one running CacheBuilder first. I tend to select "Don't start Cachebuilder" so I have the opportunity to re-adjust how often items (e.g. Service Catalog, Configuration Items, etc.) sync and turn my logging level up to "ALL". Then enable the CacheBuilder service and start it. Once this gets kicked off...
4. Upgrade the remaining IIS servers. Since they aren't doing anything more than deploying a website I tend to run task in parallel. Then go in and change things such as ensuring the AppPool doesn't time out and initializes after a restart
5. At this point - CacheBuilder and your IIS farm is running and you've upgraded to the latest portal

Now in the event something fails, a customization doesn't work, or anything is out of the ordinary I would:

1. Stop IIS across all of the servers. Stop Cachebuilder
2. Perform a DB restore of ServiceManagement pre-upgrade
3. Re-run the installer for the Portal for a previous version

But snapshotting VMs and reverting back also accomplishes the same thing. You're simple just going back to a previous point in time (e.g. pre-upgrade) as though the upgrade never happened.

Now as far as anything special to think about pre-upgrade is if a development environment is available, test deploy there first. Not only can you practice the upgrade yourself, you can also test any internal customizations you may have made.

Shane_White

Hi @Martin_Strbavy,

To answer your first question about the CacheBuilder, the one running it should be updated first although it wouldn't make a massive difference if you didn't! However the CacheBuilder Service should be running on only 1 server and should be disabled on the other 3 servers.

Your high level steps you have listed look very good and great for best practice if you are doing backups/snapshots or any Servers or Databases beforehand!

Thanks,
Shane.

Martin_Strbavy

Thanks to both for fast answers. I am planning to test  update and all customizations in test environment. But it is nice to have confirmed that my plan is +- OK. 

Martin