Microsoft KB Archive/934007

From BetaArchive Wiki
< Microsoft KB Archive
Revision as of 18:37, 18 July 2020 by 3155ffGd (talk | contribs) (importing KB archive)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Knowledge Base


Description of Antigen Enterprise Manager (AEM) 9.0 and of steps to troubleshoot issues

Article ID: 934007

Article Last Modified on 10/3/2007


APPLIES TO

  • Microsoft Antigen Enterprise Manager 9.0


Important This article contains information that shows you how to help lower security settings or how to turn off security features on a computer. You can make these changes to work around a specific problem. Before you make these changes, we recommend that you evaluate the risks that are associated with implementing this workaround in your particular environment. If you implement this workaround, take any appropriate additional steps to help protect the computer.
Important This article contains information about how to modify the registry. Make sure that you back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:

256986 Description of the Microsoft Windows registry


SUMMARY

This article describes the major components of Microsoft Antigen Enterprise Manager (AEM) 9.0. This article also explains how these components work together with the major features of AEM and with Microsoft technologies and protocols.

You can use the knowledge of how AEM works to help diagnose the cause of any issue that may occur as you work with AEM. This article lists steps to troubleshoot issues. Also, this article describes the log files and the other information that the development team requires if an issue must be escalated to the development team.

This article contains important notes and a list of known issues to help you avoid issues. The article also includes a "frequently asked questions" section to help improve your understanding of AEM.


INTRODUCTION

This article describes technical information that can help you debug and diagnose issues that may occur when you use Microsoft Antigen Enterprise Manager (AEM) 9.0. This is not a “how to” article.

For more information about how to complete tasks in AEM, view the Microsoft Antigen Enterprise Manager User Guide. To do this, visit the following Microsoft Web site:

http://www.microsoft.com/technet/antigen/2006/aem/ch1.mspx


AEM is distributed software. This means that the application runs on a collection of independent computers. However, this collection of computers appears to be a single system. Therefore, it is a complex task to diagnose issues.

For example, you may see an error message in one location. However, many different components, computer systems, and network scenarios have to be considered. Diagnostic logs or event logs from one system cannot be used to diagnose an issue. Instead, during diagnosis, you must consider diagnostics from many systems. Additionally, you must consider information about network configuration and about firewalls.

This article contains a high-level overview of AEM, and it describes the four major components. These components are as follows:

  • Web Console
  • SEMServices
  • Database
  • Remote Agents/Statistics

This high-level overview of AEM also describes the following items:

  • Four major features in AEM
  • The interaction between each component
  • The AEM components, the Microsoft technologies, and the communications protocols that are being used

Diagnostics information appears at the end of each section. The diagnostics information provides suggestions about how to troubleshoot the most common errors. This troubleshooting information includes the steps that you can take to diagnose the problem, and it describes the log files that are required by the development team if the issue is escalated.

MORE INFORMATION

What is new in AEM 9.0

AEM 9.0 adds the following new or improved features:

  • Compatibility with Microsoft Antigen 9.0
  • Enterprise-level replacement for Antigen Quarantine Manager
  • Enterprise-level replacement for Antigen Central Manager
  • Compatibility with Microsoft Windows Server 2003 Service Pack 1 (SP1)
  • Improved security and stability


Note AEM 9.0 has been rigorously tested to maintain security and stability under more rigorous operating conditions than in earlier versions of AEM

  • Removal of dependency on Microsoft Windows Management Instrumentation (WMI)

AEM overview

AEM consists of the following four components:

  • Web Console
  • SEMServices
  • Database
  • Remote Agents/Statistics

The Web Console, SEMServices, and Database components are all located on a single server. Remote Agents are located on servers throughout the enterprise that are running Antigen.

Note In computing terms, “enterprise” refers to every system that is located throughout a worldwide site.

Web Console overview

You can use Microsoft Internet Explorer to access AEM through the AEM Web Console component. To do this, type http://Computer_Name/semconsole in the Address box in Internet Explorer, and then press ENTER.

Note In this entry, Computer_Name is a placeholder for the name of the AEM server.

When you do this, Internet Explorer connects to the AEM Web Console component. The AEM Web Console component generates the user interface Web pages that are displayed in the connecting browser.

The following technologies are used to connect to the AEM Web Console component:

  • Microsoft Internet Information Services (IIS) 5.0 or IIS 6.0
  • Microsoft .NET Framework runtime version 1.1.4322
  • ASP.NET version 1.1.4322
  • COM+
  • Microsoft Message Queue and Microsoft Message Queuing Triggers
  • Microsoft Internet Explorer 5.5 or later versions of Internet Explorer

Notes

  • When the Web browser connects to IIS, it uses the HTTP protocol through port 80.
  • You must install, update, and configure IIS manually before you install AEM.
  • When AEM is installed, a folder is created in IIS in the following folder:

    c:\program files\Microsoft Antigen Enterprise Manager\SEMConsole

The SEMConsole folder stores many of the files that are used to create the user interface. The following files are located in the bin folder in the SEMConsole folder:

  • ASPX files: These files resemble .asp pages. These files contain HTML code together with code that retrieves data and formats the page.


These pages usually reference code that is located in the bin folder. However, you cannot gain additional information if you look through the files in the bin folder.

  • Web.config file: This file is a configuration file for the SEMConsole Web site. This file is customized to contain information that is required to operate AEM. Do not modify this file.
  • .Dll files: These files contain the code that is used by the ASPX files to connect to SEMServices and to perform actions such as the following actions:
    • Authenticate the user
    • Retrieve data that is stored in the database
    • Start deployments

When you view an AEM Web Console component, the following process occurs:

  1. IIS receives the request through port 80.
  2. IIS examines the SEMConsole Web site and the .aspx file name extension of the page. IIS uses this data to find the configuration information for SEMConsole and for .aspx. Then, IIS determines which application can handle the request. In this case, the request is handled by Aspnet_isapi.dll.

    To view the site configurations, follow these steps:
    1. Click Start, click Run, type compmgmt.msc, and then click OK.
    2. Expand Services and Applications, expand Internet Information Services (IIS) Manager, expand Web Sites, and then expand Default Web Site.
    3. Right-click SEMConsole, and then click Properties.
    4. On the Virtual Directory tab, click Configuration in the Application settings area. The Application Configuration dialog box opens. The Application extensions list shows that ASPX maps to the following location:

      C:\WINNT\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll

  3. IIS passes the request to the Aspnet_isapi.dll library. This is the library that invokes the ASP.NET runtime process.

    Alternatively, the request is passed to the Aspnet_wp.exe process under the Aspnet account. Then, the request is handled by ASP.NET.
  4. ASP.NET locates the Web.config file in the SEMConsole directory. Then, ASP.NET determines that ASP.NET should impersonate the SUSR_Machine_Name account because the request is from AEM. Then, ASP.NET loads the .aspx file from disk, as follows:
    • If this is the first time that the file is loaded, ASP.NET will copy the file to a shadow directory in the following location:

      C:\Windows\Microsoft.NET\Framework\v1.1.4322\Temporary ASP.NET Files\semconsole

      From this folder, the file is processed to make requests as fast as possible in the future.
    • If the file has been requested previously, the file already exists. In this case, ASP.NET directs the request to the files in the shadow directory.
  5. AEM is now located in the shadow directory. AEM interprets the request, gathers information by using SEMServices, and replies with an HTML-encoded page for IIS to display.

Why you should understand how the Web Console component works

The Web Console component involves lots of technology that can fail. When you try to diagnose a problem, you must be able to distinguish between the following types of errors:

  • Errors that occur because of an IIS/ASP.NET misconfiguration
  • Errors that occur because of AEM code
Errors that occur because of an IIS/ASP.NET misconfiguration

After you install AEM, you may not be prompted for a password, and you may be unable to move to any page when you try to move through the console. The most likely cause of this issue is an IIS/ASP.NET misconfiguration.

Note If you were able to access any page before you installed AEM, this issue is not caused by an IIS/ASP.NET misconfiguration. For example, if you could access the "At a glance" Web page or the "User Management” Web page, this issue is not caused by an IIS/ASP.NET misconfiguration.

When an IIS/ASP.NET misconfiguration occurs, you may receive an error message. The most common error messages that you may receive are as follows:

The page cannot be found.

Server Error in '/SEMConsole' Application. Access denied to 'C: \Program File\Microsoft Antigen Enterprise Manager\SEMConsole\Default.aspx'. Failed to start monitoring file changes.

Server Error in '/SEMConsole' Application. The resource cannot be found.

To resolve these errors, follow these steps:

  1. Uninstall AEM.
  2. Uninstall the .NET Framework runtime.
  3. Reinstall AEM. The .NET Framework will automatically be installed.

If the error is still not resolved, follow these steps:

  1. Check the IIS configuration. To do this, follow these steps:
    1. Click Start, click Run, type compmgmt.msc, and then click OK.
    2. Expand Services and Applications, expand Internet Information Services (IIS) Manager, expand Web Sites, and then expand Default Web Site.
    3. Right-click SEMConsole, and then click Properties.
    4. On the Virtual Directory tab, click Configuration in the Application settings area.
    5. In the Application Configuration dialog box, verify that ASPX is listed in the Application extensions list. Additionally, verify that ASPX maps to the following location:

      C:\WINNT\Microsoft.NET\Framework\v1.1.4322\aspnet_isapi.dll

  2. Start Windows Explorer, locate the directories that are listed in the following table, and then verify that the SUSR_Machine account has the correct rights assigned to it.
    Directory SUSR_Machine account right
    C:\Program Files\Microsoft Antigen Enterprise Manager\SEMConsole Read only
    C:\Windows\Temp Read, write, delete (Look at advanced tab)
    C:\Windows\system32 Read only
    C:\Windows\assembly Read only
    C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 Read only
    C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\ Temporary ASP.NET Files Read only
    C:\Inetpub\wwwroot Read only

If you receive any other error message, search the Microsoft Knowledge Base and the Internet for additional suggestions before you contact the development team. To search the Microsoft Knowledge Base, visit the following Microsoft Web site:

http://support.microsoft.com/default.aspx?scid=FH;EN-US;KBHOWTO


Errors that occur because of AEM code

Typically, errors that are related to AEM code may occur when you use the Web Console component. This is named the AEM console. The most common errors that may occur are as follows:

  • When you click a button, the expected action does not occur.
  • You receive an error message in the user interface. For example, you may receive the following error message:

    An error occurred retrieving QA-VM-RUSSIAEX1:ManageMachineId

    Error messages such as this are related to the last command that you sent. To troubleshoot this error, you must consider what you did just before you received the error message. For example, did you receive it during an agent deployment, during a package upload, or during a package deployment?
  • You receive an exception screen. For example, you may receive the following exception message:

    Server Error in '/SEMConsole' Application. Object reference not set to an instance of an object.

    The exception screen that is generated by the AEM code differs from the ASP.NET configuration exception because the stack trace contains a reference to Microsoft.SEM.

To escalate this issue to the development team, you must obtain the following information:

  • The event logs
  • The AEM logs
  • The steps to reproduce the problem

For more information about how to enable diagnostics logging, see the “How to enable AEM log files” section.

SEMServices overview

The core of AEM consists of the user interface and the database. The SEMServices component consists of all the technologies that are not related to the user interface and to the database.

SEMServices consists of many Microsoft technologies. These technologies include the following technologies:

  • DCOM
  • Message Queuing and Message Queuing Triggers
  • COM+
  • The .NET Framework

DCOM provides a communications protocol for agents that work on remote computers. DCOM is used to communicate back to SEMServices with notifications such as alerts and installation progress reports.

All communication between AEM and the agents is performed by using DCOM. Two DCOM components are registered on the AEM server. These components are the Deployment Agent and the Notification Agent.

  • The Deployment Agent is the same agent that runs on client computers. However, the Deployment Agent is run under the SADM_Machinename account on the AEM server. The Deployment Agent is responsible for signature redistribution.
  • The Notification Agent is located only on the AEM server. The Notification Agent runs under the credentials of the user who starts it. The Notification Agent is responsible for receiving notifications from remote servers and for posting these notifications to Message Queuing for processing.

COM+ is a Microsoft technology that is used for distributed applications, for transactional applications, and for component-based applications. COM+ is common in Web applications because it provides object pooling and connection pooling. This means that code and connections over the network can be reused. This process increases responsiveness, and it reduces the load on databases and on other objects that are located over the network. The COM+ objects in SEMServices exist only on the AEM server.

To view the COM+ objects we have created on the AEM server, follow these steps:

  1. Click Start, click Run, type c:\windows\system32\com\comexp.msc, and then click OK.
  2. Under Component Services, expand Component Services, expand Computers, expand My Computer, and then expand COM+ Applications.

Notice that there are two COM+ applications for Antigen. These applications are Microsoft.SEM.Services and Microsoft.SEM.NotificationSender.

When you expand Microsoft.SEM.Services and Microsoft.SEM.NotificationSender, the components and the roles are displayed. Roles resemble DCOM access permissions, and they determine which users can access the services.

When you view the properties of an individual package, you can see all the configuration tabs that you would see for a DCOM object. The Security tab is the most important to AEM, because this tab specifies which account is used to run the program. Microsoft.SEM.Services and Microsoft.SEM.NotificationSender list the SMGR_Machinename account as their “run as” account.

No direct errors are discussed in this section. Most COM+ errors that may occur are code-related, and they are not caused by the configuration of the environment. Therefore, diagnostics of this component are discussed in the context of a specific user error scenario.

Database overview

Microsoft SQL Server Desktop Engine

As part of the installation prerequisites, Microsoft SQL Server Desktop Engine (MSDE) is installed on the AEM server. MSDE is a scaled-down version of Microsoft SQL Server. MSDE contains all the data that is required for AEM. Additionally, MSDE contains the scheduler that is used to run jobs.

The SEMServices component is the only component that can access the database directly. All other communication from clients and from the front-end Web server must be directed through SEMServices to access the database.

The MSDE configuration is automated. When MSDE is installed, it is installed in its own instance. This instance is named SEMDB. Therefore, the version of SQL Server that is installed by AEM can co-exist with an existing installation of SQL Server or of MSDE.

If you receive an error message during the MSDE installation process, search the Microsoft Knowledge Base for articles that address the error message.

MSDE requires a computer name that has no more than 15 characters. If the computer name is longer than 15 characters, you receive an error message that states that the database does not exist.

SQL Server

If you want to install AEM in an enterprise environment in which the AEM databases are stored on an existing SQL Server server, you must first complete the following prerequisites:

  1. Create the following databases:
    • SybariEnterpriseManager
    • SybariEnterpriseManagerReports
  2. Note the name of the SQL Server server that is to be accessed.
  3. If you will be using Windows Integrated Security to connect to a remote SQL Server server, note the domain where SQL Server and AEM are located.
  4. Note a user name and a password for SQL Server or for Windows Authentication.

Important You must have granted access to both the SybariEnterpriseManager and the SybariEnterpriseManagerReports databases to the specified user. Additionally, you must grant db_owner permissions to the specified user.

Important AEM is incompatible with Microsoft SQL Server 2005. If you run SQL Server 2005, you must select the Express install mode (MSDE) option during the AEM setup process.

Agents/Statistics overview

The only component of AEM that runs on client computers is the Deployment Agent. The Deployment Agent is used to monitor remote systems. The Deployment Agent is a pure DCOM object. DCOM enables you to communicate to the agent to perform the following tasks:

  • Template and package deployment, and template and package installations
  • Signature downloads and signature updates
  • Statistics retrieval
  • Agent communication back to AEM (such as alerts)

Troubleshooting scenarios

The following scenarios describe errors that may occur in AEM, and they describe steps to resolve each error.

Scenario 1: You have problems when you deploy an agent to a remote server

Part 1

When agents are deployed to remote systems, only code from SEMServer is involved. However, deployment can be complex because of interactions that occur on the remote systems. The protocols that are involved during deployment are UNC/SMB and DCOM.

Consider the following scenario:

  1. To deploy an agent, you move to the SEMConsole’s Server Management screen, select a server, and then click Deploy Agent.
  2. You are prompted for a user name and a password for a user who has administrative rights on the remote system.
  3. The deployment begins. Log messages are sent back to the status page. You receive the following error messages on the status screen:

    Invalid username or password

    Error adding network connection: The credentials supplied conflict with an existing set of credentials

    Note You receive the second error message if you previously connected to the remote computer by using a different set of credentials.

    For example, you receive this message if you mapped a remote drive by using one user name and password in Microsoft Windows, and then you tried to map another drive to the same computer by using different credentials.

Typically, AEM handles this situation successfully, and the error message goes away if AEM is inactive for about five minutes. However, you can break the connection immediately by going into Component Services and then restarting SEM services. To do this, follow these steps:

  1. Click Start, click Run, type c:\windows\system32\com\comexp.msc, and then click OK.
  2. Under Component Services, expand Component Services, expand Computers, expand My Computer, and then expand COM+ Applications.
  3. Right-click Microsoft.SEM.Services, and then click Shutdown.
Part 2

Part 2 of this scenario describes issues that may occur when AEM deploys the agent to the remote server. AEM sends status messages during the deployment. You can use the AEM status messages to help diagnose what AEM was doing immediately before an error occurred.

The following table describes the status message that is sent by AEM, and it describes what occurs when the status message is sent.

AEM status message What occurs when the status message is sent
Connecting

AEM connects to the admin$ share on the remote computer.

AEM creates a temp directory in the following remote admin share:

\\machine\admin$\temp


Copying files to remote share AEM copies the deployment agent files to the remote temporary directory. (AEM pushes the files to the remote computer by using the UNC/SMB protocol.)
Starting remote installer AEM remotely registers and then starts the Pushinstaller.exe file that was copied to the temporary directory as a Windows NT service.


AEM connects to the PushInstaller service to begin the remote installation. DCOM is used for this operation.

Creating the SEMDeployment user The SEMDeployment account is created by using administrative rights so that you can reconnect later.
Installing the Agent
Installing DeploymentAgent The Deployagent.msi file is installed. This file was previously copied to the temporary directory. This process provides AEM with a permanent agent by which to communicate with Antigen and with the remote system.


Permissions are set on the Deployment Agent DCOM object. These permissions limit access to the SEMDeployment account.

Checking DeploymentAgent installation AEM connects to the deployed agent on the remote computer for verification.


The installation process is complete.

Typically, errors occur during installation because of misconfigurations, because of firewalls, or because of locked files on the remote system. Any error messages that you receive when you connect to the remote server come from the Windows operating system.

To determine the cause of a connection error, map a drive to the "\\machine\admin$" share on the remote server. Do this by using the same user name and password that you tried to use through AEM. If this procedure does not work, a firewall or some other misconfiguration is blocking the connection. Contact the network administrator to help you resolve this issue on the server side.

When you try to deploy AEM, you may receive the following error message:

Failed to deploy the Agent. Reason: The requested operation cannot be performed on a file that has a user-mapped section open.

This issue occurs if you tried to deploy AEM previously and were unsuccessful, and then you tried to deploy AEM again. Usually, this error message means that the Pushinstaller.exe process is still running on the remote server. If this file is locked, you cannot deploy the agent remotely.

To resolve this issue, locate the \\machine\admin$\temp folder on the server, and then delete the Pushinstaller.exe file.

If you cannot delete the Pushinstaller.exe file, remotely log on to the server, open Task Manager, and then end the Pushinstaller.exe process. Alternatively, you can stop the Pushinstaller.exe process in Service Control Manager, and then delete the Pushinstaller.exe file.

Note If you cannot stop the Pushinstaller.exe process in Task Manager, use Kill.exe. Kill.exe is available in the Windows Server Resource Kit.

If Pushinstaller.exe is not running but you still receive the error message, some other program has locked the executable file. To determine which application has locked the executable file, use the Handle program. To obtain the Handle program, visit the following Microsoft Web site:

http://www.microsoft.com/technet/sysinternals/ProcessesAndThreads/Handle.mspx


In the Handle program, run the handle pushinstaller command. You should be able to determine what program has locked the Pushinstaller executable file.

If this issue must be escalated to the development team, you must obtain the following log files:

  • The Application event logs from the AEM server
  • The Security event logs from the AEM server
  • The SEMLog log file (see the "How to enable AEM log files" section)
  • The Application event logs from the remote server
  • The Security event logs from the remote server

Scenario 2: You have problems when you deploy an installation package or a template

After an agent is installed on the remote server, the user can deploy a package or a template file to the remote system.

The process that is used to deploy packages to remote servers is slightly more complex than the process to deploy the agent. This is because the process that is used to deploy packages involves two computers. Each computer performs independent actions.

To help clarify the process, the following scenario separately describes the process that occurs on the AEM server and on the remote server.

The process that occurs on the AEM server

An existing job reaches its runtime as was specified in the SQL Server scheduler when the job was created. Alternatively, you click Run now to start the job manually. In both cases, the SQL Server scheduler calls code in SEMServices to start the job. A message appears in the Application log under SQLAgent$SEMDB to indicate that the job began.

Then, SEMServices performs the following procedure:

  1. AEM retrieves the installation files or the template files that are associated with the job or with the package that is being deployed. The files are copied locally to the following redistribution folder:

    \\SEMServer\SybariRedistribution$

    This redistribution folder is physically located in the AEM directory in the following location:

    c:\Program Files\Microsoft Antigen Enterprise Manager\SEMServices\Redistribution

  2. AEM posts a message to the Notification Agent that the job has started.
  3. AEM retrieves the user name and the password for the remote server. The user name and the password were saved when the agent was deployed.

    If the agent was not deployed, the following error message is recorded in the event log:

    The AEM Deployment username/password are not configured for server Server_Name

    Note This error message also appears in the AEM logs that are sent to the development team for diagnosis.
  4. AEM creates the DeployAgent DCOM object on the remote server.
  5. AEM sends commands to the remote server to complete the following actions:
    • Download the package that is to be installed locally
    • Run the installation or the Antigen starter for templates
    • Send a notification that the job has ended
  6. AEM moves on to the next server, and AEM initiates the jobs for that server. After the commands are sent, AEM no longer takes an active role in the deployment. All remaining aspects of deployment, of the actual installation, and of notifications that are returned are handled by the remote computer.

Notifications are received by AEM

During the installation process, the remote system periodically posts status message to AEM. AEM receives these status messages through the Notification Agent. The Notification Agent performs the following procedure:

  1. A message is received from a remote server by using the SNTF_Computer account.
  2. The Notification Agent takes the message, decodes the message, and then writes the message to Message Queuing.
  3. Message Queuing is configured to use a trigger rule that calls in to SEMServices to process the message.
  4. AEM Services processes the message and then writes the message to the database, where the message appears in the Status column.


Note This is the process that is used for all messages that are processed by the Notification Agent.

The process that occurs on the remote server
  1. The server creates the DeployAgent object as requested by AEM.
  2. The server receives the redistribution directory from AEM together with the package to download. The redistribution folder is \\SEMServer\SybariRedistribution$.
  3. The remote server posts a notification back to AEM that states that the server is beginning the download process. The server uses DCOM and the SNTF_Computer account on AEM to post to the Notification Agent.


Note For more information about how the message is processed, see the "Notifications are received by AEM" section.

  1. The remote server downloads the files locally to a temporary directory.
  2. The remote server begins the installation by unpacking the compressed file, by running security checks to make sure that the files have not been tampered with, and then by running the SEMInstall.exe file from the installation package.
  3. The installation program is now Microsoft Antigen 9.0 for Exchange, Sybari Antigen 8.0 for Microsoft Exchange, or Sybari Antigen 7.5 for Microsoft Exchange. Antigen for Exchange posts notifications back to AEM that report on installation progress.


The whole installation process is controlled by the installer utility. The process is not controlled by AEM. AEM uses the same Setup.exe file that Antigen usually runs in silent mode.

How to troubleshoot issues that occur during deployment of an installation package or of a template

Depending on when an error occurs, you must take various diagnostic measures. Use the description of the process to help you determine what the problem is. When a deployment is unsuccessful, follow these steps to determine when and where this problem occurs:

  1. Verify that the following directories exist on the server:

    \\SEMServer\SybariRedistribution$
    c:\Program Files\Microsoft Antigen Enterprise Manager\SEMServices\Redistribution

    1. Verify that the share can be accessed from a remote system.
    2. Use the Search feature to locate the file that is being deployed under the Redistribution\packages directory for the Template.adb file or for the Antigen installation file that was uploaded.

      For example, use the Search feature to locate the following file:

      a80ex_1470_eval_intel_sophos_ndd_cairis_cavet.exe

  2. If no messages are displayed, view the Security log on the AEM server for the logon successes and failures of the SNTF_Computer account.
  3. If messages are not being displayed, or if you receive only one initial message, verify that Message Queuing is installed.

    Additionally, verify that messages are not building up. To do this, follow these steps:
    1. Click Start, click Run, type compmgmt.msc, and then click OK.
    2. Under Computer Management, expand Services and Applications, expand Message Queuing, expand Private Queues, expand Microsoft.sem.notification, and then click Queue Messages. The pane on the right should be blank.
    3. Right–click microsoft.sem.notification, and then click Properties.
    4. On the Security tab, verify that the Everyone group is assigned Receive Message permission and Peek Message permission.
    5. If any permission is missing, or if you see lots of messages building up in the queue, Message Queuing and Message Queuing Triggers are misconfigured. This condition results in no messages being posted back to the user.
  4. View the Application log on the computer that is running AEM to determine whether the computer that is running AEM is connected to the remote system.
  5. To verify that DCOM can be used to connect to the remote server, try to map a UNC share to the remote server. Additionally, try to connect the local service control manager to the remote server.

    This procedure helps you determine whether the computers are behind a firewall and whether the computers can make a DCOM connection to the remote server.

Things to verify on the remote server

  • View the Application log on the remote server to determine whether any error messages are recorded from the Deployment Agent about how to access the Notification Agent on AEM.

    For example, look for user name and password errors for the SNTF_Computer account.
  • Verify that the SEMDeployment account is configured correctly. To do this, follow these steps:
    1. Click Start, click Run, type compmgmt.msc, and then click OK.
    2. Expand System Tools, expand Local Users and Groups, and then click Users.
    3. Verify that the SEMDeployment account exists.
    4. Double-click SEMDeployment, and then click to select the Password never expires check box.
    5. Click to clear the User must change password at next logon check box, and then click OK.
  • Use Windows Explorer to make sure that the following folder exists:

    Windows\temp\SybariCache\

  • Search the Windows\temp\SybariCache\ folder and its subdirectories for the image that you tried to deploy. This image is the same .exe or .adb file that was originally uploaded as a package.
  • View the following file to locate any errors:

    c:\Antigeninstall.log

If you must escalate the issue to the development team, you must obtain the following log files:

  • The Application log and the Security log from the AEM server, and the Application log and the Security log from the remote server


Note Also include the System log from the AEM server and from the remote server if these logs are available.

  • The SEMLog log file


Note For more information about this log, see the "How to enable AEM log files" section.

  • The Antigeninstall.log file, if it exists
  • Comments about what happened when you performed the procedures that are described in this section

Problems that may occur when AEM updates signature files

AEM updates signature files. AEM polls the Antigen Web site to determine whether updates for signature files are available. AEM then obtains the updated signature files. After the updated signature files are downloaded and are available for clients, AEM notifies all the client computers about the updates. Then, the client computers retrieve the updates from the AEM server.

The signature files update process occurs on the AEM server as follows:

  1. A scheduled update job is created by the user. The job is saved to the SQL Server scheduler.
  2. At the designated time, the SQL Server scheduler starts the job. The SQL Server scheduler calls SEMServices to perform the signature files update process. The SQL Server scheduler writes to the Application log on the SEMServer that the update job began.
  3. SEMServices connects to the Antigen Web site by using the site settings, the engine files, the proxy settings, and the other settings that were configured when the job was created.

    SEMServices actually uses code from the GetEngineFiles command internally to perform the same type of download that Antigen does. Errors that occur when SEMServices connects to paths or to remote systems are logged in the Application log.
  4. The signature files are downloaded and then saved in the following folder:

    c:\program files\Microsoft Antigen Enterprise Manager\SEMServices\Redistribution\SybariTemp

  5. After the files are completely downloaded, AEM moves the files to the Scan_engine_updates folder in the SybariCache folder. The files are saved by using the same file format that is used on the Antigen Web site.

    The folder is shared to other computers by using the SybariRedistribution$ share name.
  6. From the database, AEM obtains a list of the computers to which the updates are to be deployed.
  7. For each computer, AEM marks the system in the database as "synchronized." Then, AEM notifies the remote Deployment Agent on each computer that updated signature files are available.

    A UNC share deploy agent must be able to connect to the following folder:

    \\SEMServer\SybariRedistribtuion$\scan_engine_updates

  8. The remote server sends notification messages back to AEM as information becomes available.

As the signature files update process continues, notification messages are sent to the Notification Agent to provide the status of the updates to AEM. The Notification Agent performs the following procedures:

  1. A message is received from a remote server by using the SNTF_Computer account.
  2. The Notification Agent takes the message, decodes the message, and then writes the message to Message Queuing.
  3. Message Queuing is configured to use a trigger rule that calls SEMServices to process the message.
  4. SEMServices processes the message and then writes the message to the database, where it appears in the Status column.


Note This is the process that is used for all messages that are processed by the Notification Agent.

  1. If the message specifies that the download was unsuccessful, AEM marks the server in the database as "not synchronized." At the next download interval, AEM tries to deploy signatures to that server, even if no new files are downloaded from Antigen. This process helps make sure that systems that are offline are updated when they come back online.

The signature files update process occurs on the remote server as follows:

  1. The remote server receives a DCOM connection to the Deployment Agent.
  2. The Deployment Agent connects back to the UNC path that is provided by AEM. Then, the Deployment Agent downloads the updated signature files locally.

    These files are first stored in the following folder:

    C:\Windows\Temp\SybariTemp

    The files are then moved to the SybariCache folder after the copy process is complete.
  3. The Deployment Agent runs Antigen’s copy of the GetEngineFiles command to update only the new engines together with the path of the local temporary folder where the files were staged. The local temporary folder is as follows:

    C:\Windows\temp\SybariCache

  4. The GetEngineFiles process runs locally, and it updates Antigen.
  5. Success messages or failure messages are sent from the GetEngineFiles process to the local Deployment Agent. The Deployment Agent sends messages to the Notification Agent on AEM to provide the status of the update to AEM.

How to troubleshoot signature files update issues

The procedure that is used to troubleshoot signature files update issues resembles the procedure that is used to troubleshoot issues that occur during deployment. If the updated signature files could not be downloaded by the AEM server, the client computer will also have error messages. Errors that occur early in the signature files update process are propagated throughout the system.

What to troubleshoot on AEM
  1. Determine which protocol and which path AEM is using to download the updated signature files.

    Important Do not use the following path:

    http://ftp.sybari.com

    This path will not work.

    Note AEM requires only the site. AEM does not require the whole path. This behavior differs from that of Antigen.
  2. Use Windows Explorer to determine whether the following folder exists:

    \\SEMServer\SybariRedistribution$

  3. Use Windows Explorer to determine whether the following folder exists:

    c:\Program Files\Microsoft Antigen Enterprise Manager\SEMServices\Redistribution

  4. Verify that the following share can be accessed from a remote system:

    \\SEMServer\SybariRedistribution$

  5. Search the following folder to determine whether the signature files that are being downloaded exist:

    Redistribution\ scan_engine_updates

    If the signature files exist, verify that the .ini file is correct and is the most recent version.

If the items in step 4 and in step 5 are verified to be correct, the error occurred during redistribution. View the Application log on the AEM server to determine whether any entries were logged for failures to connect to the remote system. These errors will help you pinpoint download errors.

What to troubleshoot on the remote server

Use Windows Explorer to view the following folders:

  • C:\Windows\Temp\SybariCache
  • C:\program files\Microsoft Antigen Enterprise Manager\SybariTemp

Determine whether the signature update files exist in the SybariCache directory. If the files exist, the files were successfully downloaded to the remote system. If the files do not exist, the error occurred during the download process. To troubleshoot this issue, follow these steps:

  1. In Event Viewer, view the Application log to determine whether any errors about the download process are recorded.
  2. Try to map a UNC share to the remote computer by using DCOM. Do this to verify connectivity to the remote server.


Additionally, try to connect the local service control manager to the remote computer. This process confirms that you are not behind a firewall, and it confirms that you can obtain DCOM connections to the remote computer.

In Event Viewer, view the Application log on the remote server to determine whether any events about the download failure are recorded.

For example, when a download is not completed, the following event is frequently found in the Application log on the computer that is running Antigen: ERROR: Unable to create GetEngineFiles Mutex, hr = 5, Account = SEMDeployment

This error occurs when both AEM and Antigen are scheduled to complete a download at the same time. If both programs run at the same time, one program will fail and the other program will succeed. However, this is not a problem because the system is successfully updated.

To avoid this issue, stagger AEM updates and Antigen updates so that the updates occur at different times. We suggest that AEM be updated every 30 to 60 minutes and that Antigen be updated one time per day.

For example, when a download is not completed, the following events are frequently found in the Application log on the computer that is running Antigen: Event Type: Error
Event Source: GetEngineFiles
Event Category: (6)
Event ID: 6063
Date: Date
Time: Time
User: N/A
Computer: Computer_Name
Description: The description for Event ID (6063) in Source ( GetEngineFiles ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: GetEngineFromHTTP function failed.

Event Type: Error
Event Source: DeploymentAgent
Event Category: None
Event ID: 0
Date: Date
Time: Time
User: N/A
Computer: Computer_Name
Description: Error "Access is denied." (0x80070005) creating notifier on "SEMServer"

If you received the "access is denied creating notifier" error, and if the message that comes before this error is "GetEngineFromHTTP," AEM is not running the signature files update.

AEM runs by using only UNC. Therefore, AntigenService is scheduling updates for the client. The account under which AntigenService is running does not have permissions to access the AEM notification mechanism. This condition caused this error to occur. This behavior is expected because AEM is not triggering the update. AEM will try to suppress this message in the future.

If you must escalate the issue to the development team, you must obtain the following log files:

  • The Application log and the Security log from the AEM server, and the Application log and the Security log from the remote server


Note Also include the System log from the AEM server and from the remote server if these logs are available.

  • The SEMLog log file


Note For more information about this log, see the "How to enable AEM log files" section.

  • The Antigeninstall.log file, if it exists
  • Comments about what happened when you performed the procedures that are described in this section

Problems that occur with statistics gathering and reporting

Overview of statistics gathering

AEM and Antigen can perform enterprise-wide reporting. Statistics can be viewed and can be reported from a group of servers instead of from each server.

Statistics are gathered and correlated on each computer that is running Antigen. This means that statistics are kept by Antigen for 15 minutes before the statistics are flushed out to disk.

By default, AEM polls the computers that are running Antigen and then retrieves the data that has been flushed to disk every 240 minutes. The retrieval rate can be changed to as short as every 15 minutes by using the global configuration.

Alternatively, you can use the Poll now feature. However, the Poll now feature retrieves only data that was already flushed to disk. Statistics about anything that occurred in the past 15 minutes may not appear yet.

The statistics gathering process occurs on the computer that is running Antigen as follows:

  1. Antigen detects a virus, detects spam, or detects a message.
  2. Antigen keeps a count of all the viruses, all the spam, and all the messages since the last time that Antigen flushed to disk.
  3. At the 15-minute time interval, Antigen contacts the AntigenStatisticsService service. Then, Antigen sends the service all the statistics counts that Antigen has accumulated.
  4. Antigen resets its counts to zero. Then, Antigen continues to keep counts for each new message until the next time that it must flush (approximately 15 minutes).
  5. The AntigenStatisticsService service writes the information to the Statistics.xml database that is located on the local computer.

The statistics gathering process occurs on the AEM server as follows:

  1. AEM reaches its polling interval as configured in the global configuration.
  2. AEM retrieves the list of servers from the local database.
  3. AEM connects to the Deployment Agent (DCOM) on each server to retrieve statistics.
  4. AEM receives the statistics information. Then, AEM writes the information back to the MSDE Antigen Enterprise Manager Reports database.

The statistics gathering process occurs on the remote server as follows:

  1. The Deployment Agent receives the request from AEM for statistics.
  2. The AntigenStatisticsService service connects to the local Statistics.xml file to retrieve the data.
  3. The data is sent from the AntigenStatisticsService service to the Deployment Agent. The Deployment Agent formats the data as XML and then passes the information back to the AEM server.

Note AEM waits for the statistics information that AEM polls to come back directly to AEM. AEM does this instead of letting the statistics information come back through a notification mechanism.

How to troubleshoot problems that occur with statistics gathering and reporting

Most errors that occur with statistics gathering and reporting are caused by communication errors between AEM and the remote system.

To determine where the error is occurring on the AEM side, follow these steps:

  1. View the Application log in Event Viewer to determine whether errors are recorded about the connection to the remote computer. If such errors are recorded, follow these steps:
    1. Connect to the remote computer by using a UNC share to determine whether a DCOM connection can be made.
    2. Connect the service control manager to the remote computer.
    3. Connect the Antigen client to Antigen on the AEM server. If Antigen cannot connect, DCOM may not be functioning correctly.
    4. Make sure that the client has deployed an agent to the remote computer. If an agent was not deployed, DCOM cannot connect.
  2. View the Application log in Event Viewer to determine whether the following message from SQLAgent$SEMDB is recorded:

    SQL Server Scheduled Job 'StatisticsJob

    If the message exists, follow these steps:

    1. Run the Poll Now feature from the client computer to poll the server. Do this to make sure that the job was triggered.
    2. Change the polling interval by one minute, and then save the job. For example, change 15 minutes to 16 minutes.
  3. Enable AEM logging, and then click Poll now. For more information, see the "How to enable AEM log files" section. This procedure may provide more detailed data about errors that are occurring internally.

To determine where the error is occurring on the Antigen side, follow these steps:

  1. Make sure that the AntigenStatisticsService service is running.
  2. Verify that the Statistics.xml file exists in the following folder:

    C:\Program Files\Microsoft Antigen for Exchange

If you must escalate the issue to the development team, you must obtain the following log files:

  • The Application log and the Security log from the AEM server, and the Application log and the Security log from the remote server


Note Also include the System log from the AEM server and from the remote server if these logs are available.

  • The SEMLog log file


Note For more information about this log file, see the "How to enable AEM log files" section. After you enable the SEMLog log file, perform a “run now” operation on the signature update job, and then select Start Download.

  • Comments about what happened when you performed the procedures that are described in this section

How to enable AEM log files

To enable AEM log files on the AEM server, follow these steps:

  1. Start AEM, type http://Localhost/Semconsole/Semlogsettings.aspx in the Address box, and then press ENTER.

    Note This path is a hidden path.
  2. In the TEXT File Log area, click to select the Write to Text Files check box, and then click Save.
  3. Reproduce the problem.
  4. In AEM, type http://Localhost/Semconsole/Semlogsettings.aspx in the Address box, and then press ENTER.
  5. In the TEXT File Log area, click to clear the Write to Text Files check box, and then click Save.
  6. Retrieve the log files from the following folder:

    %Documents and Settings%\Settings\All Users\Application Data\Microsoft\SEM\Log Files

To enable AEM log files on the managed server for remote logging, follow these steps.

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

  1. Click Start, click Run, type regedit, and then click OK.
  2. Expand the following registry subkey:

    HKEY_LOCAL_MACHINE\SOFTWARE\Sybari Software\SEM\1.0

  3. Click 1.0, right-click TraceTextWriter, and then click Modify.
  4. Note the value in the Value data box.
  5. In the Value data box, type 1, and then click OK.
  6. Right-click TraceEventLog, and then click Modify.
  7. Note the value in the Value data box.
  8. In the Value data box, type 1, and then click OK.
  9. Right-click TextFileTraceCategory, and then click Modify.
  10. Note the value in the Value data box.
  11. In the Value data box, type 16, and then click OK.
  12. Reproduce the problem.
  13. Change the values in the Value data boxes back to the values that you noted in steps 4, 7 and 10.
  14. Retrieve the log files from the following folder:

    %Documents and Settings%\Settings\All Users\Application Data\Microsoft\SEM\Log Files

Important notes

  • AEM must be installed on an application server.
  • AEM cannot be installed on a server that is configured to be a domain controller.
  • AEM cannot be installed on a server that is running the following software and services:
    • The Active Directory directory service
    • Microsoft Windows SharePoint Services
    • Microsoft SharePoint Portal Server
  • AEM is designed to work with Antigen 9.0 or later versions of Antigen.
  • If you decide to install AEM in a folder other than the default folder, the path of that folder must not contain non-ASCII characters. Some functions may not work if AEM is installed in a folder whose path contains Unicode characters.

    The path can contain characters from the following groups:
    • Letters (A to Z, a to z)
    • Numbers (0 to 9)
    • Symbols (: \ ! # $ % ' ( ) + , - . ; = @ [ ] ^ _ ` { } ~)
  • AEM can deploy only licensed versions of Antigen. AEM cannot deploy evaluation versions of Antigen.
  • AEM does not perform an upgrade or a reinstallation directly. Instead, AEM uninstalls the earlier version first.

    The current database is preserved during an uninstallation process. During the installation process, click Yes when AEM prompts you about whether you want to attach AEM to the preserved database.
  • When you perform an enterprise installation on a SQL Server server, the AEM server and the SQL Server server must be in the same domain or be in trusted domains.
  • You may have to restart the computer after MSDE or the .NET Framework are installed. You may have to manually restart the installation after the computer is restarted.
  • AEM Web pages use machine authentication codes to protect their view state. For more information about how to troubleshoot machine authentication code issues, click the following article number to view the article in the Microsoft Knowledge Base:

    829743 Troubleshooting the "View State is invalid" error with ASP.NET

  • Unregister the Deployment Agent on a managed computer before you uninstall the Deployment Agent. To do this, type the following command at a command prompt:

    C:\Program Files\Microsoft\MAEM DeploymentAgent-9.0.1055.0\DeploymentAgent.exe /UnregServer

    Note If the Deployment Agent is not installed in the default path, change the path in this command.
  • When you upgrade to AEM from Sybari Enterprise Manager, you may have to change the download location for stored redistribution jobs. In this case, change the location from http://www.sybari.com to http://Antigendl.microsoft.com/Antigen.

Known issues

  • If you decide to browse the network when you try to add users, you may be unable to see trusted domains.
  • When you try to use a SQL Server server that has more than 15 characters in its name, you receive the following error message:

    SQL Server does not exist or access denied

    You cannot work around this issue.
  • If you install Sybari Enterprise Manager to a path that is longer than 128 characters, some operations may be unsuccessful.
  • E-mail reports cannot be scheduled for every hour. This issue occurs because reports that run before the polling interval do not present accurate data to the user.
  • If you try to deploy the Deployment Agent to a managed server that already has a Deployment Agent installed, you may receive the following error message:

    Access is denied creating the SDEP_User_Name user.

    To resolve this issue, deploy the Deployment Agent again.
  • To install AEM in an enterprise environment that is running Microsoft Windows Server 2003, grant "Logon as batch" permission to the user who is installing AEM. This procedure enables the Test Logon feature and the Check Database feature on the database computer.
  • When you try to deploy a Deployment Agent for the first time to a server that has AEM installed, the deployment is unsuccessful. To resolve this issue, grant the SDEP_Computer_Name account the "Logon as batch" permission in the Local Security Policy policy.
  • If the Deployment Agent is deployed to the same server where AEM is installed, AEM will be affected if the Deployment Agent is uninstalled. If you want to uninstall both AEM and the Deployment Agent, uninstall AEM first, and then uninstall the Deployment Agent.

    If you uninstall the Deployment Agent first, you receive the following error message:

    Failed to unregister Pushinstaller. Contact support personnel.

    You can safely ignore this error message.
  • You cannot use the built-in SQL Server administrator "sa" account when you use an enterprise installation together with SQL Server security tools. Instead, you must create a regular SQL Server account and then assign the appropriate permissions to the account.
  • When you run AEM on a computer that is running IIS 6.0, make sure that the WWW service is not configured to run in IIS 5.0 isolation mode. AEM will not operate correctly if the WWW service is configured to run in IIS 5.0 isolation mode.
  • When you upgrade Sybari Enterprise Manager to AEM, the engines report may contain duplicate entries for some servers. One entry will have the correct information. The other entry will have information from before the upgrade.
  • Microsoft Windows Server 2003 Service Pack 1 (SP1) changes the security level of the computer. After you install Windows Server 2003 SP1, you must follow these steps so that AEM can work correctly with a remote server.

    Warning This workaround may make a computer or a network more vulnerable to attack by malicious users or by malicious software such as viruses. We do not recommend this workaround but are providing this information so that you can implement this workaround at your own discretion. Use this workaround at your own risk.
    1. Click Start, point to Administrative Tools, and then click Component Services.
    2. Expand Component Services, and then expand Computers.
    3. Right-click My Computer, and then click Properties.
    4. On the COM Security tab, click Edit Limits in the Launch and Activation Permissions area.
    5. In the Group or User names list, click Everyone.
    6. In the Permissions for Everyone area, click to select the Remote Launch Allow check box, and then click to select the Remote Activation Allow check box.
    7. Click OK.

  • Use Event Viewer to view the events on a server that is monitored by AEM. Determine whether the following event is recorded in any of the logs:

    Error “Access is denied” creating notifier on “[AEMMachineName]”

    If you locate this event, follow these steps:

    1. Log on to the server where AEM is installed.
    2. Click Start, point to Administrative Tools, and then click Component Services.
    3. Expand Component Services, and then expand Computers.
    4. Right-click My Computer, and then click Properties.
    5. On the COM Security tab, click Edit Limits in the Launch and Activation Permissions area.
    6. In the Group or User names list, click Everyone.
    7. In the Permissions for Everyone area, click to select the Remote Launch Allow check box, and then click to select the Remote Activation Allow check box. Click OK.

Frequently asked questions

  • What is the URL to access the AEM console from a remote computer?

    To access AEM from any computer, use the following URL:

    http://Machine_Name/semconsole

  • Which versions of Antigen can AEM manage?

    AEM can manage only Antigen 9.0. You cannot use AEM to manage or to collect statistics for versions of Antigen that are earlier than 9.0.
  • Does the AEM installation utility automatically install all the prerequisite components if the components are missing? For example, will the utility install IIS 6.0, .NET Framework runtime version 1.1, or ASP.NET version 1.1?

    The AEM installation utility will install all the prerequisite components except IIS 6.0. For security reasons, you must manually install IIS.
  • Is an active SMTP service required for correct AEM functioning?

    No. However, if you want to send e-mail messages about incidents, you must configure AEM to send messages to an SMTP server that can relay the messages to the desired recipients.
  • Can I create my own custom reports?

    Yes. AEM stores all its statistical data in MSDE. MSDE is a scaled-down version of SQL Server. MSDE is compatible with many third-party reporting products.
  • Why do AEM pages sometimes take a long time to load?

    This behavior usually occurs the first time that you move to a page. AEM adjusts itself to the environment under which it is running the first time that a page is loaded. This process provides quicker response times for later loads.
  • If I leave AEM for a while and then hit a page, why is AEM slow to respond?

    When AEM is left inactive, it unloads itself from memory to conserve resources. When you start using it again, AEM reloads dynamically. However, the initial reload process involves a short delay.
  • If I leave AEM inactive for 20 minutes, why am I prompted to log on again when I resume working?

    For your security, AEM automatically logs you out after 20 minutes of inactivity. If it is necessary, you can adjust the time-out parameter of the sessionstate item in the Web.config file that is located in the SEMConsole folder.
  • What should I do with my Antigen signature update jobs?

    We recommend that you do not schedule AEM and Antigen updates for the same time. Instead, disable scheduling on the Antigen client. Rely on AEM to perform the updates.

    In unstable networks, you may have concerns about the possibility of the AEM server going down. As a best practice in this case, we recommend that you use AEM as the main update mechanism. (AEM downloads occur every 15 minutes or so.) Configure Antigen updates to occur one time per day per scan engine.
  • Should I configure one or many signature update jobs?

    When one update job tries to update many signatures at the same time, and when the update job then tries to distribute the signatures to many Antigen computers, the AEM server may not have enough time to distribute everything.

    AEM will try again to distribute the signatures. However, errors will be recorded in the logs. When this occurs, use many signature update jobs instead of one update job. Schedule these jobs at different times.
  • What is Sybari Enterprise Manager, and how does it relate to AEM?

    Sybari Enterprise Manager is the name for older versions of AEM. In AEM 9.0, you may still see some names that contain the acronym "SEM" (for example, SEMConsole).


Keywords: kbinfo kbtshoot kbexpertiseadvanced KB934007



Send feedback to Microsoft

© Microsoft Corporation. All rights reserved.


Retrieved from ‘https://www.betaarchive.com/wiki/index.php?title=Microsoft_KB_Archive/934007&oldid=228511’
the Creative Commons 3.0 ShareAlike (except the Microsoft KB Archive).
Powered by MediaWiki