How to change a Symantec Endpoint Protection client from unmanaged to managed in MR3 and above using the Sylink Drop utility

Question/Issue:
How do you manually establish communication between a Symantec Endpoint Protection client and the Symantec Endpoint Protection Manager?

Symptoms:
Clients and the SEPM (Symantec Endpoint Protection Manager) are not communicating. There is no green dot embedded in the gold shield on the task bar of the client and the client does not show in the console, or if it does appear, it does not have a green dot . The green dot indicates that communication is successful.

Solution:
To export the Sylink.xml file:

1. In the console, click Clients

2. Under View Clients, select the group in which you want the client to appear

3. Right-click the group, and then click Export Communication Settings

4. In the Export Communication Settings for group name dialog box, click Browse

5. In the Select Export File dialog box, locate the folder to where you want to export the .xml file, and then click OK

6. In the Export Group Registration Setting for group name dialog box, select one of the following options:

■ To apply the policies from the group from which the computer is a member, click Computer Mode

■ To apply the policies from the group from which the user is a member, click User Mode

7. Click Export

To use the SylinkDrop tool to apply the Sylink.xml file:

1. On Disk 2 of the installation CDs, locate the \Tools\NoSupport\SylinkDrop folder, and open SylinkDrop.exe

2. Take the exported sylink and the SylinkDrop.exe to the client

3. Execute SylinkDrop.exe

4. In the Sylink Drop dialog box, click Browse, and locate the .xml file that you exported

5. Click Update Sylink

6. If you see a confirmation dialog box, click OK

7. In the Sylink Drop dialog box, click Exit

Note: SylinkDrop.exe does not provide a progress indicator. Upon completion, it displays a window with the text "Sylink file has been successfully replaced."

If you want to convert a managed client to an unmanaged client, please see "How to convert Symantec Endpoint Protection clients from managed to unmanaged without uninstalling and reinstalling" at http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008021910355348

Source: http://service1.symantec.com/support/ent-security.nsf/docid/2009030314365748?Open&seg=ent

An event ID 6002 that references Distributed File System replication is logged several times a day on a Windows Server 2003 R2-based computer

Symptoms

The following event ID 6002 that references Distributed File System replication (DFSR) is logged in the Application log several times a day on a Windows Server 2003 R2-based computer:

Event Type: Error
Event Source: DFSR
Event Category: None
Event ID: 6002
Date: Date
Time: Time
Computer: Computer_Name
Description: The DFS Replication service detected invalid msDFSR-Subscriber object data while polling for configuration information.
Additional Information:
Object DN: CN=2762160d-2aea-4aec-8076-635e0a33cd5c,CN=DFSR-LocalSettings,CN=KFS1,CN=Computers,D C=Domain_Name,DC=Root_Domain
Attribute Name: msDFSR-MemberReference
Domain Controller: Domain_Controller_Name.Domain_Name.Root_Domain
Polling Cycle: 60 minutes

Cause

This issue occurs because of an invalid DFSR object in the Active Directory directory service. Invalid DFSR objects can occur if you select the Delete the namespace folders and associated replicated folders option in the DFS Management snap-in. Because that option may cause objects that are orphaned in Active Directory, we recommend that you first delete the replication group from the DFS Replication node in DFS Management. Then, delete the DFS Namespace.


Resolution

Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

To resolve this issue, remove the object that is the cause of the error by verifying DFS subscriptions. To do this, follow the steps in the "Connect to Active Directory" and "Remove the invalid object" sections.

Note These steps only resolve the issue in which an invalid object exists in the Active Directory directory. The steps do not resolve replication issues.

Connect to Active Directory

1. On a server that has the Windows Support Tools installed, open a command prompt. To download the Windows Server 2003 Support Tools, visit the following Microsoft Web site:
   http://www.microsoft.com/downloads/details.aspx?FamilyID=96a35011-fd83-419d-939b-9a772ea2df90&displaylang=en
2. Move to the Drive_Letter:\Program Files\Support Tools folder.
3. Type adsiedit.msc, and then press ENTER.
4. On the Action menu, click Connect to.
5. In the Connection Settings dialog box, type any name that you want to name this connection in the Name box.
6. In the Connection Point area, click Select a well known Naming Context, and then click Domain.
7. In the Computer area, click Select or type a domain or Server, and then type the fully qualified domain name (FQDN) of the server. Or, you can click Default (Domain or Server that you logged in to), if this option is appropriate for your situation.
8. Click OK.

Remove the invalid object

1. Expand Domain [Server_Name.Domain_Name.Root_Domain].
2. Expand DC=Domain_Name,DC=Root_Domain.
3. Expand CN=Computers.
4. Expand the node for the computer that is logging the errors. For example, expand CN=Computer_Name, where Computer_Name is the name of the server that is logging the errors.
5. Expand CN=DFSR-Local Settings.
6. Under the CN=DFSR-Local Settings node, click each object in the navigation pane until you see an object in the details pane that has a GUID that matches the one that you observed in the event log. For example, to match the event that is listed in the "Symptoms" section, you should see an object that has the following distinguished name:
   CN=2762160d-2aea-4aec-8076-635e0a33cd5c,CN=DFSR-LocalSettings,CN=Computer_Name,CN=Computers,DC=Domain_Name,DC=Root_Domain
7. Right-click the object that you identified in step 5, click Delete, and then click Yes.
8. Exit ADSI Edit.

From: http://support.microsoft.com/kb/953527

WSUS Self-update is not working

I've noticed a number of WSUS 3.0 servers are coming up with the following error in the Application event log:

Event Type: Error
Event Source: Windows Server Update Services
Event Category: Clients
Event ID: 13042
User: N/A
Computer: WSUS01
Description: Self-update is not working.

To fix the issue, follow these steps:

• Open IIS Manager and ensure there is a Selfupdate virtual directory in the Default Web Site. If not, create it with the Local Path pointing to C:\Program Files\Update Services\Selfupdate


• Click the Directory Security tab and ensure that Anonymous Access is allowed


• Restart IIS

Verify that the problem is fixed by running the following command at the command prompt:

C:\Program Files\Update Services\Tools\wsusutil.exe checkhealth

Then examine the Application event log for the following event:

Event Type: Error
Event Source: Windows Server Update Services
Event Category: Clients
Event ID: 10000
User: N/A
Computer: WSUS01
Description: WSUS is working correctly.

As background, WSUS clients must connect to the SelfUpdate virtual directory to check for a new version of the WSUS client before checking for new updates. This always happens anonymously over port 80, even if WSUS is configured to use a custom port, such as port 8530.

Credit: http://www.expta.com/2008/06/fix-for-self-update-is-not-working-in.html