Symantec Management Platform (Notification Server)

Following the migration guide very carefully:

- Installed a new NS7.1 box, win 2008 R2 x64

- Selected ITMS

- Pointed it to my existing 7.X CMDB

- Installed OK, seemed fine

Now I can't get in to my NS7 box at all.  "Access Denied.  YOu currently do not have sufficient network access rights to the Notification Server console".  The service accounts are the same on both 7.1 and 7.0.  Same SQL database.  The SIM on the 7 box tells me that the products are not configured correctly, but attempts to repair the SMP on the 7 box result in a critical error "Failed to add the proposed app identity to the Symantec Administrators Group".  Even though the app identity IS in the SYmantec Administrators group.

Problem is that I'm using this as a POC for the migration.  The new 7.1 box seems to see all the old data, machines, asset data etc.  But I can't run the migration tool of course, because the 7.0 server is essentially broken.

Any ideas?

Hi Wallo,

You're not getting access to Altiris 7.0 because now the database was reconfigured to Altiris 7.1 schema.

The correct step would connect to a restored instance of the 7.0 Configuration Management Database (CMDB).

Please take a look at this article: http://www.symantec.com/business/support/index?page=content&id=HOWTO43979#v47642825

"The migration of data from Symantec Management Platform 7.0 to Symantec Management Platform 7.1 requires two steps. In the first step, you connect to a restored instance of the 7.0 Configuration Management Database (CMDB). You connect to the 7.0 CMDB in Symantec Installation Manager on the Database Configuration page when you install the Symantec Management Platform products. Symantec Installation Manager upgrades the existing 7.0 CMDB to the 7.1 schema. This step migrates all of the data in the 7.0 CMDB. In the second step, you use the migration wizard to migrate the data that is not in the CMDB. This data includes KMS keys, packages, security settings, and general Symantec Management Platform settings."

Could you go ahead with the Altiris migration? Would you like to restore the Altiris 7.0 funcionality before?

Let us know what do you think about the next steps, ok?

As Luke mentioned, you must use a restored copy of your 7.0 database.

So, in the following environment:

• 7.0 SMP with SQL off-box on SQL 2005 server
  DB Name: Symantec_CMDB
• Windows Server 2008 R2 box ready for 7.1 SMP installation

You would back up Symantec_CMDB and restore it as Symantec_CMDB_71.  Then install SIM on Windows Server 2008 R2, configuring SMP 7.1 and solutions, pointing to the restored Symantec_CMDB_71 database.  The upgrade takes the Symantec_CMDB_71 database from the 7.0 schema to the 7.1 schema, and you now have two functional environments: SMP 7.0 SP5 using Symantec_CMDB database and 7.0 agents reporting to it, and SMP 7.1 using Symantec_CMDB_71 database with no agents reporting to it.

Once confirming the migration was successful and your 7.1 server is healthy, you'd begin migrating site servers and agents, repointing them from 7.0 to 7.1.

As far as what to do now, if you need to keep using 7.0 (recommended), restore your SQL database from backup as Symantec_CMDB_70 and reconfigure your SMP 7.0 to use this database.  Or, turn off your 7.1 server and restore the database as Symantec_CMDB.  You shouldn't need to repoint your 7.0 server in that case, making things a little easier.

Alternatively, you can start using 7.1.  Clients can be redirected manually using the AeXAgentUtil.exe /server: command.  But as always be sure to verify new server health and test agent migrations before doing anything en masse.

I certainly think it could be more clear, because I did the exact same thing in my pre-production environment.  I remember glossing right over the word 'restored' and thought to myself, even after two readings, "How interesting that 7.0 still functions properly under the 7.1 schema, especially considering the changes to security and account management."

Turns out it can't.  The reason why your 7.0 server isn't functional, among others, is that 7.0 used local security groups in Windows to determine security, while 7.1 uses accounts stored in the CMDB for security.  The database does not believe anybody in 7.0 has rights for access.

Thanks guys.  After going through the 167 page migration document I missed that point... I imagine that my customers will too, as I'm normally pretty thorough with that sort of thing...

So... MY BAD!!! (Punching myself in the head right now)

I only realised there was a problem when I attempted to run the migration tool on the 7 box and discovered that the migration tool refused to migrate software management components... Then I tried to log in and found the issue.

I'll go ahead and restore a copy of the old NS db and point the NS7 box to that.

I might add too that the only reason I'll need to restore it is because I am changing my clients over to SSL, since that's what Symantec are pushing these days (Luke - please confirm if I'm wrong here)... So as part of the migration I am also moving my clients across to use SSL as part of it.  So if the old NS isn't working my only choice is to use the aexagentutil /server /web to force them to SSL.  Otherwise the standard redirect won't work as the old NS isn't working.  Never mind, I'll try some restorations and see if that helps.

Thanks again.