Endpoint Protection

 View Only

Startup Scripts and SylinkDrop…Better Together 

Jul 14, 2009 11:56 AM

This article is part of a series describing how to leverage Group Policy Software Installation to install SEP. All automatically and without touching SEPM when you deploy a computer.

GPO Installs and SEP, Part 1
How to leverage Group Policy Software Installation to install SEP Clients.
https://www-secure.symantec.com/connect/articles/creating-transform-mst-file-control-installation-symantec-endpoint-protection

GPO Installs and SEP, Part 2
How to turn GPO-installed SEP Clients into Managed Clients and assign them to the correct Group. Even if you don’t use GPO installs, this article makes your SEP installation more robust.
https://www-secure.symantec.com/connect/articles/startup-scripts-and-sylinkdrop-better-together

GPO Installs and SEP, Part 3
How to comply with Symantec’s supported upgrade path for MP installations.
https://www-secure.symantec.com/connect/articles/mp-upgrade-path-compliance-using-group-policy

___________________________________________________________________

What does this do for me?

Well, that kinda depends on who you are.

I install SEP by Group Policy and use OU-imported SEPM Groups.

With this technique, you can use one install point for all Group memberships, and use the default, unmanaged Sylink.xml furnished by Symantec. This is really handy for keeping your system current with Symantec’s frequent MR/MPs with minimal administrative fuss. (And isn’t minimizing administrative fuss what we all live for?)

I install SEP by Group Policy and I use SEPM Groups that are not imported from OUs.

If your OUs were designed long before SEPM and don’t map perfectly to SEP configurations, or you want to work around the “duplicate client” OU Group bug unfixed as of SEP 11.0 MR4 MP2 (and that would be me!), or you just like the simplicity of having only a few nodes in the Clients tree in SEPM instead of the dozens or hundreds of nodes you’d have to import from AD, then you can use one install point, and have clients placed in the correct SEPM Group automagically.

I install SEP using SEPM’s push installer. Or SMS/MSSC. Or Altiris. Or a batch file on my workstation and PSEXEC. Or [MyPreferredMethod­®]. And I’ve puzzled it all out. And it works just fine. And they all find a SEPM. And all clients are all in the right groups. Thank you very much. So I don’t need this, right?

Congratulations on your significant achievement!

But let’s pretend you have a few domain-member workstation computers to which SEP was successfully deployed by your brilliant, insightful choice of installation methodology. And you have 2 or more SEPMs, which these SEP clients know about. But…

…a few workstations were offline for a while after their users were terminated for browsing pronography sites.

While those clients were offline, you ended up replacing all your SEPMs due to hardware failure, scheduled hardware refresh, OS upgrade, or because some other machine became available that was a more suitable SEPM than one you already had. Or you have just one SEPM in a microbusiness system that became inaccessible when SEPM authentication blew up, so you had to do a fresh SEPM reinstall. (Or…whatever…work with me, here: We all run dynamic systems on microbudgets in sub-optimal conditions. You know bad things are bound to happen. I’ve personally been involved in two of these scenarios; you guess which ones.)

And then, suddenly, you need those offlined workstations for a new employee. When those SEP clients boot up, good old Group Policy will make sure they're current, right?. Except, SEP is not going to find a SEPM unless you intervene.

Or, unless you follow these simple instructions.

Okay, okay, I’m a believer. Sheesh!

Great. Then first, we’re going to standardize on terminology.

If you import your SEPM Groups from Active Directory Organization Units, we’re going to call them OU Groups.

If you create your Groups in SEPM, and they’re not linked to Active Directory, we’re going to call them SEPM Groups.
  1. If you want to map OUs to SEPM Groups, right-click each Group in SEPM to which you want to add SEP clients and choose Export Communications Settings and skip to step 5.
  2. Note: This menu command was added in SEP 11.0 MR3. On prior versions, you can still obtain the correct SYLINK.XML, but it requires a (rather arcane) process, documented here: service1.symantec.com/support/ent-security.nsf/docid/2007082009543848)
  3. If you use OU Groups, or use SEPM’s push installer, the only Group whose Communication Settings you need to export is Default Group.
  4.  Export Communication Settings
  5. Select Computer Mode, and enter or browse for a path and filename for the exported file, and click Export. (Symantec's default filenames are, surprisingly, useful and consistent, and I recommend them,.)
  6.  Export Communication Settings Dialog Box
  7. If you use SEPM Groups, open the Computer Configuration\Windows Settings\Scripts node in Group Policy Editor for a GPO linked to the OU you want to associate with a SEPM Group. Skip to step 8.
  8. If you use OU Groups, create a GPO that is linked to all SEP Clients.
  9. Double-click Startup Scripts.
  10. Now, you probably have your own preferred method for proper handling of Startup Scripts. But to simplify the documentation, I’m showing you the method that requires the least explanation. So do this however you like, and I don’t want to hear any complaints about Startup Script best practices, OK?
  11. Click Show Files, and copy the appropriate SYLINK.XML file you previously exported into the folder.
  12. Also copy SylinkDrop.exe from the Tools\NoSupport\SylinkDrop folder of your SEP media’s CD2 into the folder. Then close the Folder.
  13. Click Add and browse for SylinkDrop.exe.
  14. Enter the Parameters as shown. Substitute the password required to restart the SMC service for password. If you do not require a password to stop the SMC service, omit the -p switch and password entirely (duh.).
  15. Startup Script Properties
  16. Click OK twice, and sync your domain controllers if you have more than one.

How can I test this?

  1. Install SEP as an unmanaged client on a test computer in the scope of the OU where you just added the Startup Script. Or use SylinkDrop interactively to make an existing SEP client unmanaged.
  2. Refresh Group Policy on the test computer.
  3. Restart the test computer. By the time you log on, SEP should be registered in the correct Group in SEPM, and Help/Troubleshooting in SEP should confirm the correct SEPM Server and Group.

Are there any gotchas?

Of course!
  1. These instructions assume you have SylinkDrop v1.1. I think that’s the only version I’ve ever seen, and I probably first used it with SEP 11.0 MR2 MP1, but I couldn’t swear to it. It is definitely included with SEP 11.0 MR4 MPx. If you have an older version of SylinkDrop, this may not work.
  2. I think this will only work for Computer Mode SEP configuration unless your users are local Administrators<shiver>. We’ve only documented Startup Scripts in this article. But I think if your users are local Administrators<shiver> the same principle should apply for Logon Scripts. But I’ve never tried it with Logon Scripts, and my users are not local Administrators<shiver>, and we don’t currently use any User Mode configs. So you’re on your own.
  3. Automatic placement of a SEP Client in a Group will only work for SEP clients installed as unmanaged clients. Fortunately, this is easy for AD admins to do with GPO installs! Just include the SYLINK.XML file that Symantec furnishes in the SEP setup folder in your network setup share. This is a limitation of SylinkDrop, but it may be overcome (see below).
  4. Once a client is moved to a Group, the Startup Script will not be able to move it to a new group if the client’s OU changes. You will have to move it manually. If this functionality is important to you, the limitation might be overcome, however.

What’s the trick to moving a Client to a new Group with this method?

I have been told by Symantec support that the no-Group-move limitation will be lifted in a future version of SylinkDrop. When it is, this method will allow computers to change Groups when their OU changes. And, one hopes, without any modification to the SylinkDrop command lines in our Startup Scripts. (Symantec, please make it easy for us.)

If you can’t wait for Symantec to update SylinkDrop, post your requests here, because I have an idea for a script that will very likely work. It’s just not currently a big issue for my clients so I haven’t done it. The script will also have the advantage of shaving a few seconds off of bootup time.

Note that the no-Group-move limitation of SylinkDrop does not prevent SEP clients from finding a new SEPM if all the SEPMs they know about vanished after a lengthy period of being offline. Given a current Sylink.xml, SylinkDrop will force Clients to contact available SEPMs.

If the system uses OU Groups, SEPM will ensure that the client joins the right Group as long as PKI and DNS/IP data exists in the Sylink.xml for at least one valid SEPM.

If you use SEPM Groups, my guess is that the client will rejoin the preferred Group (if exported from MR3 or higher) if it still exists. Or if not, it will be banished to Default Group so you can move it interactively in SEPM. But I haven’t tried that. Symantec, feel free to advise us!

Any ideas on how to use this for User Mode configs if my users aren’t local Administrators<shiver>?

I don’t use any User Mode configs, and none of my users are local Administrators<shiver>, so I have to confess I don’t know. But I suspect that HKLM has to be modified for User Mode configs as it is for Computer Mode configs. If so…it might work as a Scheduled Task run under System credentials scheduled to run at logon. So that’s my great idea. But I’ve never tried it. Here’s an opportunity for someone else to grab 200 Connect Points if I don’t get there first. And may the best SEP admin win.

When do I need to update the Sylink.xml files?

  1. When you create or remove a SEPM. As long as there is at least one current SEPM in the Sylink, it will contiinue to work, but if a client is offline for long enough for all its known SEPMs to be replaced, it will need a new Sylink.xml in order to remain managed.
  2. Whenever you create, remove, or rename a SEPM Group where you use this technique to apply the Sylink.xml to an OU.
  3. Whenever Symantec changes the Sylink.xml format.

You keep talking about deploying SEP by Group Policy, but…

…while I see that Symantec supports GPO installs, it’s sure not very well documented! Especially about how to control which SEP components are installed on each client. Group Policy could manage this extremely well—if I only knew how<sigh>.

Friend, <sigh> no longer. See www-secure.symantec.com/connect/articles/creating-transform-mst-file-control-installation-symantec-endpoint-protection for more information about managing Group Policy SEP installs with MST files. And while you're there, make sure vote up your favorite author<ahem>.

Statistics
0 Favorited
4 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Comments

Mar 18, 2011 07:58 AM

Hello,

Good job done and a good information.

Mar 06, 2010 02:32 PM

Hi,

The following article did not work for me. Running the SylinkDrop.exe does not run with the Group Policy startup parameters.

"How to turn GPO-installed SEP Clients into Managed Clients and assign them to the correct Group. Even if you don’t use GPO installs, this article makes your SEP installation more robust."

However I combined the principle of the article of using Group Policy and Batch Script. I used a batch due to my limited scripting skills. "If you can write a better vbscript or Windows Powershell, please can you post it !"

I decided not to create custom groups but instead configured the directory server options an imported the Active Directory OUs.

SEP_1.JPG


1. Next step is to create a Group Policy and use the Shutdown Script option. I tend to prefer to use the Shutdown script option as oppose to the Startup script. This is ensure the PC startup is as fast possible for the user. So the user has the best user experience! Also most users do not wait for a PC to shutdown!

2. Create group containing the Unamanged SEP clients in Active Directory and filter the group policy using this Group. Link the GPO to the relevant OU. This will ensure only the unmanaged SEP clients get the Group policy applied to them.


SEP_2.JPG


3. The SEP.bat file

====================================================================

@echo off
 
echo "Set mappings" >NUL: 2>&1
Net Use U: /D >NUL: 2>&1

Net Use U: \\Myfileserver\share\Software >NUL: 2>&1
U:\SylinkDrop.exe -silent "U:\My Company_Computers_sylink.xml"

Pause 30

Net Use U: /D >NUL: 2>&1

End

========================================================================

4. Create a share on your Fileserver which can be access by the unmanaged SEP clients. In the software folder put a copy of syslinkdrop.exe and your sylink.xml file.

5. If you have 1000s of unmanaged SEP clients. As they become managed, you should remove them from the group. I would advise doing this periodly, until all SEP clients become managed. Once this is finished you can delete the group and custom group policy. 
 You can get this infomation about SEP client that have become managed from the following.
 

SEP_3.JPG




5. Hope this makes this easier !



















































 

 

Sep 16, 2009 10:43 AM

I created a script that I uses and export from my domain computers as an input file for a psexec routine.   

http://www.fishandscripts.com/?p=23 

Jul 19, 2009 10:21 PM

This is good work..
you got my vote...

Related Entries and Links

No Related Resource entered.