I’m trying to work through our CMS migration from 8.1 RU7 to 8.5. We’ll be moving to new server(s) because our existing install is on 2008r2 servers.
Restoring the database and running NSUpgradeWizard theoretically seems to get us most of the way there (it seems to give us ability to move patches, tasks, and software items), but it seems like the deployment solution part of the suite is not migrated, is that correct?
I understand images need to be updated for the new version of the client (8.5), but typically we’d restore those images, let the client update, and then re-upload the updated image. It seems odd to me that TECH251847 doesn’t mention that images and copy file resources aren’t gathered by the migration wizard/database restore. I assume Deployment tasks and jobs come over but am not sure.
The ITMS Data Migration PDF has DS migration steps (page 30-36) for standalone migration.
If I’m understanding everything above correctly, since most of our machines are getting swapped over the next few months anyway, I’m now leaning towards not migrating anything and instead starting fresh with new win10 machines going to new NS with plan to shut down old NS after our rollout.
My only complication with that is for the few month overlap where we have old machines on one NS and new machines on new NS where we need ability to image on same VLAN. Support suggested we could leave NBS services stopped on the server least used until it’s needed and then swap back and forth stopping/starting services between the 2 services depending on if we’re imaging a new or old machine. I’m assuming there’s no better way to manage 2 iPXE installations on same VLANs?
thanks for any thoughts.
One example, from the Oracle space, is to create a child SG (storage group) for the Oracle data files (e.g. data_sg) and another for the redo logs (e.g. redo_sg). Aggregate them under a parent SG (e.g. database_sg). Then use the parent for operations that relate to the whole database:
1. Masking view.
2. Remote replications with SRDF (create a consistency group that includes both data and logs).
3. Local database snapshots using SnapVX (a snapshot containing both data and log is considered ‘restartable’ and you can use it to instantiate new copies of the database, or as a ‘savepoint’ before patch update or for any other reason).
However, if you need to recover production database, you only want to restore data_sg and not redo_sg (in case the online redo logs survived, as they contain the latest transactions). Therefore, although the snapshots are made with the parent (database_sg), you can restore just the child (data_sg), and proceed with database recovery – all the way to the current redo logs.
Another advantage is separate performance monitoring of the database data files and logs. When using the child SG’s you can monitor them separately for performance KPIs without the redo logs metrics mix up with the data files.
Finally, with the introduction of Service Levels (SL’s) back into the code, you can use them differently on the child SG’s if you so wanted (e.g. Silver for data_sg, gold for redo_sg, etc.)
Just wanted to share with everyone that in my experience upgrading from 3.2 RU7 to 3.3 the System DSN for the “Altiris eXpress Database” is not created correctly or damaged after a 3.3 upgrade. I’ve had two separate GSS machines fail to launch the Console after installing 3.3 because the database couldn’t be found. If you’re looking to upgrade make sure to backup the registry key HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeODBCODBC.INIAltiris eXpress Database and its contents before installing, just to be safe.