Client Management Suite

 View Only

Lessons learned from SMP 7.5 SP1 HF3 installation 

Apr 14, 2015 11:12 AM

First, a bit of information about our environment. We have been using Deployment Solution 6 for years. Up until a few months ago, our general deployment has been with 6.9 SP5 MR3 or 6.9 SP6 servers. We felt the desire to be able to target more dynamic groups of computers rather than simply static targets, and so wanted to move to Symantec Management Platform 7.5 to help accomplish this. We've had the infrastructure built up for this, but never had full buy-in from the team actually using the images and so it was decided that with some contracted support, we could finally make this change.

We contracted to have some assistance to validate our Symantec Management Platform 7.5 SP1 HF3 with ITMS installation, and then apply best practices to help things work more reliably. Here are a few of our lessons learned, some of which have been fixed by more recent updates, some of which are still requiring a workaround to be fully functional.

Problem: When using SSL with deployment, if your server certificate/binding does not match the FQDN name of the server, the PECT agent was unable to successfully complete the computer account lookup.
Cause: When setting up CEM, tried to change the certificates to make Cloud Enabled Management work "better" and broke everything.
Solution: Wiped the server and entire database and restarted matching the FQDN and the certificate again, as it had been before.

Problem: Sysprepping an image strips out SSL certificates. We have an internal CA with certificates deployed through group policy and domain membership. This means that secure Site servers can't communicate with the agents post-image-deployment, because the CA, and by extension the SMP server, are no longer trusted.
Workaround: Copy the certificates back to the computer pre-image-capture while in Automation. Set a batch file contained in the folder to run certmgr for the 2 certificates needed (Server and CA) into the setupcomplete.cmd file to be run after the computer is imaged.
More information on this issue can be found in TECH224579. While the article says that it was an issue through HF2, it's still an issue in HF5. It may or may not be an issue in 7.6, but we haven't made that upgrade yet.

Problem: The setupcomplete.cmd file didn't run after imaging.
Solution: The SetupComplete.cmd file is case sensitive. If the capitalization isn't proper, the script won't run.

Problem: Sysprepping an image leaves the Unattend.xml in the %SystemRoot%\System32\Sysprep folder. If you told the computer to rejoin the domain, that will contain account credentials stored in plain text.
Workaround: Use a Run Script task to delete the file pre-image-capture while in Automation.

Problem: Having the DS 6.9 DAgent installed on a computer which is being Prepared for Image Capture causes problems, as the DS 6.9 DAgent will apparently wipe the setupcomplete.cmd file post imaging and possibly some other little bits. This definitely causes problems with trying to re-inject certificates post-imaging, and may also cause problems for anything else that's supposed to be part of a complicated job.
Workaround: Send an uninstall job to the DS 6.9 DAgent before you Prepare for Image Capture.

Problem: Sometimes when you have hardened security and you're provisioning a Cloud Enabled Management server, it will ask for credentials to communicate with the SMP server. Normal accounts will fail to communicate, and simply leave the server status as red/problematic.
Solution: Using the SMP service account (Application Identity) to authenticate fixes the issue. You can still use the Local System account to run the services, as suggested, but just make sure that you give it an account which can actually access your SQL server.

Problem: The Client Task Data Loader service is set to Automatic start, but requires SMP Agent to finish starting first, or it can't get status updates and wipes the status on all jobs currently in progress but uncompleted.
Workaround: Set the CTD Loader service to Automatic (Delayed) startup so that it starts around the same time as the SMP Agent, which is also set to Automatic (Delayed) startup.

Since we've already had a few times when we've referred back to these notes, we felt it would be helpful to make some of these issues and their solutions more easily available for discovery online, rather than just sitting in my email client as typed information.

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Apr 29, 2015 09:30 AM

It's not sysrep that is stripping the certificates (at least in my environment). Through iterative testing I've determined it's actually Symantec Management Agent that is doing it. If I disable it and the Symantec Management Agent Installation Service before they get a chance to do the damage, my root CA certificate exists in the store. Once I allow SMA to execute, say goodbye to the root CA (though interestingly enough my intermediate CA survives).

I'm opening a case with Symantec as this is clearly in their code, not a product of sysprep.

 

Apr 24, 2015 07:40 AM

I found that sysprep post image seems to temporarily start services even if it then stops and disables them. So even if set to stopped and disabled in the image, the setupcomplete in the image would get deleted.
That's why I have a copy of setupcomplete and use a RunSynchronous command in Unattend.xml to copy it to setupcomplete.cmd

Apr 22, 2015 12:27 PM

It's interesting because we've had inconsistent behaviour with the capitalization. Sometimes it seems to matter, sometimes it doesn't. It used to work reliably with it lowercase. Then it stopped working.
Copying the file back to the computer post-Deploy-Image but pre-Boot-to-Production with the specific capitalization made it start to work again. It's just one of those things where 'should' doesn't necessarily equal will.

Another option would be setting DAgent to disabled and stopping the service, since you're not using it to actually pull the image. Then you should just be able to have your SetupComplete.cmd change the service to start automatically (or delayed) again, and when it boots to actual live Windows after the audit boot, it should work normally.

Apr 14, 2015 06:59 PM

Thanks for a very useful article.

We got round the issue of the Altiris Deployment Agent (DAgent) deleting setupcomplete by setting the DAgent Service to Disabled prior to running Sysprep (but not stopping it) then having a RunSynchronous command in the Unattend.xml to copy setupcompletebak.cmd to setupcomplete.cmd and that setupcomplete.cmd file would re-enable and start the DAgent as the last thing it did:

start sc start "Altiris Deployment Agent"

The "start" lets the setupcomplete.cmd process exit before the start of the Service deletes it.

Didn't have the issue with the capitalisation, the problem that took me a few days to sort was that the Unattend.xml RunSynchronous command needs to be of the form CMD /C:

<Path>cmd /c "copy c:\windows\setup\scripts\setupcompletebak.cmd c:\windows\setup\scripts\setupcomplete.cmd"</Path>

Related Entries and Links

No Related Resource entered.