Symantec Management Platform (Notification Server)

I am trying to install SMP 7.1 with SQL 2008 R2 on an off box server both of which are Virtual Hosts (eSXi 5.0) running Windows Server 2008r2 64-bit. The installation of the components (SMP) appears to succeed but then at about 48% it fails with a configuration error. Before I spend too much time on the error I am interested to see if anyone has a successful production installation where the SMP and Sql are separate and running on virtual hosts. I have read a couple KB articles (HOWTO9692 and DOC1746) that strongly advise against putting sql on a virtual host but are about a year old so I am hoping to get some real world comments.

At this point I just need to know if this error is a sign of things to come, in which case I need to move SQL over to a physical server.

Thank you all,

Yes.  Add 20-25% to hardware recommendations to account for virtual overhead.  Installs do not auto-fail at 48% if you choose to install SQL virtualized.

Try installing the Platform first, and then a Suite.  If it still errors out, please refer to the Symantec Installation Manager logs, which I think are at C:\ProgramData\Symantec\SMP\Logs within a SIM folder.

I've only ever installed NS7 on Virtual hosts and have never yet hit an issue. Just make sure you've got the resource visibility to ensure you're not getting contention.

Good advice from mclemson on hitting those logs as your first port of call.

Kind Regards,
Ian./

Thank you both for your information. 

Mclemson - let me clairify a little better, I am at the platform installation phase and it is the connection to the off box SQL server that is failing, thus causing the installation of the platform to fail. I set a trace on the sql server to watch the log activity as the platform installation progressed and have identified the following based on the sql server log ( the error is below).

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

"Login failed for user 'domain\Altiris_acct'. Reason: Failed to open the explicitly specified database [Client: <IP of NS>]"

to clairfy - I am using the SIM to create a new database (Symantec_CMDB) NOT connect to existing.

Are you logged in to the SMP box as the Application Identity?

Thank you for the assistance. I would love to give a definitive resolution that included adjusting SQL perms but the problem existed on the other server. After spending a couple hours in a remote support session with Symantec support the issue could not be found and yet the installation / configuration remained incomplete. 

The solution I choose to implement was to blow the VM instance away and recreate the server. After doing so the SIM progressed through the installation of SMP 7.1 without issue.

Must have been frustrating -thanks for letting us know.  When that kind of stuff happens here, I just blame it all on cosmic rays....

Edit: As this poster was requesting real-world data on  Physical vs Virtual VMs, marking first post in that vein as solution.

I have SMP 7.1 running on a virtual host with Windows Server 2008r2 64-bit. What is the requirments for memory and CPU in a virtual environment.

Thanks

Jen

This solution to your question has already been posted here!! It's the one highlighted in camouflage green.

Same as physical with an extra 20-25% to cater for virtulisation overhead.

Sorry, my server admins are telling me the number differences are cut in half and I'm just try show them they are not correct.

Probably best not to approach it *that* way...

VMWare is primarily used to reduce physical server count, and so most admins are used to coallescing servers through virtulisation. This works for many servers as they just don't do much and can have a lot of memory space overlap. This is probably where your server guys are coming from.

What they don't yet understand is that your SMP server (the SQL server component to be exact) is going to be quite busy most of the time and your console experience is going to be quite frustrating if you are suffering from resource contention.

Kind Regards,
Ian./