Endpoint Protection

 View Only
  • 1.  SEPM "Unable to communicate with the reporting component" on SQL database

    Posted Sep 03, 2009 06:27 PM

    Already try this http://service1.symantec.com/support/ent-security.nsf/854fa02b4f5013678825731a007d06af/beb4238fecda37a588257433006db633?OpenDocument
    But it doesn´t Work.
    When I hit browse in the reporting conmponent on IIS, the msg is "unable to comunicate with the server"
    This error apperas in two new aditional sites.

    regards JPG 



  • 2.  RE: SEPM "Unable to communicate with the reporting component" on SQL database

    Posted Sep 03, 2009 06:38 PM

    If the The transaction log in the SQL server has become full it will prevent the SEPM from communicating properly with the database. then also you may get this error

     

    Please refer to the following documentation from Microsoft to clear the full transaction logs:

    http://msdn.microsoft.com/en-us/library/ms175495.aspx

    http://support.microsoft.com/kb/317375

    http://support.microsoft.com/kb/873235



  • 3.  RE: SEPM "Unable to communicate with the reporting component" on SQL database

    Posted Sep 03, 2009 10:35 PM
    Go To Run -> Type odbcad32
    click the System DSN Tab
    Select the option which is related to SEPM 
    Click Configure
    When it prompts for username, Type SA user name and Password
    Complete the wizard and it will check the Connectivity.

    goto run and type IISRESET

    Then check whether u are able to open SEPM without the error :)


  • 4.  RE: SEPM "Unable to communicate with the reporting component" on SQL database

    Posted Sep 04, 2009 01:17 AM
    hii if above documnet dont work ur IIS is currupt......
    Please re install SEPM from add/remove which will re configure ur IIS or creat new SEPM reporting site .....
    If this option dont work u can uninstall and re install IIS and again reinstal SEPM with existing DB.....will do....

    :)njoy.....


  • 5.  RE: SEPM "Unable to communicate with the reporting component" on SQL database

    Posted Sep 04, 2009 01:54 AM
    Dear PGA_CR

    Pls try this

    Reset Internet Information Services (IIS)
    In some cases simply resetting IIS can resolve this issue. Follow the steps below:
    1. Exit SEPM
    2. Click Start > Run.
    3. Type iisreset
    4. Click OK.
    5. Log into SEPM again.


    Check the IIS Configuration
      Verify IIS permissions and account(s) rights are set correctly
      Use the Microsoft IIS Diagnostics Toolkit to identify all the rights and permissions on the accounts. The toolkit is available from Microsoft at:

      http://www.microsoft.com/downloads/details.aspx?familyid=9BFA49BC-376B-4A54-95AA-73C9156706E7&displaylang=en

      Verify the DefaultAppPool identity is set to 'Network Service'
        1. Open the IIS Administrator
        2. Expand <server name> > Application Pools
        3. Right-click DefaultAppPool and select Properties
        4. On the Identity tab verify the Predefined radio button is selected and that Network Service is on the drop down list
        5. If Network Service is listed then try adding the Local System

          Note: Parts of these instructions cannot be performed with Windows XP running IIS 5.1 or Windows 2000 running IIS 5.0.
          For either, there is no "application pool in the configuration and "IP address and domain name restrictions" are dimmed in the virtual server settings.
          Microsoft purposely denies access to these settings.
      Verify user rights.
        1. Run gpedit.msc
        2. Expand Computer Configuration > Windows Settings > Security Settings > Local Policies
        3. Select User Rights Assignment in the left-hand pane
        4. Go to the Adjust memory Quotas for a Process item and double click.
        5. Verify that LOCAL SERVICE and NETWORK SERVICE are listed under the Local Security Setting tab.
        6. Go to the Replace a process-level token item and double click. Again, verify that LOCAL SERVICE and NETWORK SERVICE are listed.

          Note
          : If the "Add User or Group..." button is disabled, it may be locked by a domain GPO (group policy object) which will require an assessment of domain GPOs.
        7. Restart the IIS Admin service to update any changes
      Verify Authentication and Access Control.
        1. Open the IIS Administrator
        2. Right-click Default Web Site and click Properties
        3. On the Directory Security tab, under Authentication and Access Control, click Edit
        4. Verify that Enable Anonymous Access is selected
        5. Please select the appropriate setting if you are utilizing Authenticated Access
      If SSL is not implemented, verify that Secure Communications is not selected
        1. Open the IIS Administrator
        2. Right-click Default Web Site and select Properties
        3. On the Directory Security tab, under Secure Communications click Edit
        4. Verify Require Secure Channel (SSL) is not selected


    Re-enable logging in IIS

    Examine the IIS logs to get the full error code. The default location for the logs is C:\Windows\System32\LogFiles\W3SVC1
    In the IIS manager, right click each site where you wish to have the logs, such as Reporting and Secars, and select Log visits and click OK.

    If you have to contact technical support, have these logs ready for the technicians.


    Testing the ODBC Connection

    Note: On a 64-bit computer, a 32-bit DSN is created and is accessible via (by default) C:\Windows\SysWoW64\Odbcad32.exe.
      For an SQL database
      1. Verify the following:
        • You specified a named instance during installation and configuration. For example: \\<server name>\<instance name>
        • The SQL Server is running and properly configured
        • The network connections between Symantec Endpoint Protection Manager and the SQL database.
      2. Test the ODBC connection.
        1. Open Control Panel > Administrator Tools
        2. Double click Data Sources (ODBC)
        3. On the System DSN tab, double-click SymantecEndpointSecurityDSN
        4. Go through the wizard to ensure the following settings:

          Name: SymantecEndpointSecurityDSN
          Description: <Anything>
          Server: Servername\InstanceName
          (Only enter the server name or IP address if using the default instance)
          Login ID: sa
          Password: <password>

        5. Leave the defaults for the rest of the items and click Finish
        6. Click Test Data Source , it should return "Success"
        7. Click OK

    Check system resources

    You should have at least 1GB of RAM available. If not, CPU usage may be high and this could be affecting the issue. Refreshing the console may help temporarily but it is only a workaround and not a solution.
    Loopback address disabled Reporting pages may fail to appear if loopback addresses are disabled on the computer. If you have disabled loopback addresses on your computer, you must associate the word localhost with your computer IP address. You can use the Windows hosts file to do this. For example, on computers running Windows XP, do the following:
    1. Change the directory to the location of your hosts file. By default, the hosts file is located in%SystemRoot%\system32\drivers\etc
    2. Open the hosts file with an editor such as Microsoft Notepad.
    3. Add the following line to the file:

      xxx.xxx.xxx.xx   localhost   # to log on to reporting functions (where xxx.xxx.xxx.xx is the IP address of your computer)
    4. Save and close the hosts file.

    Remote Desktop Protocol (RDP)
    There may be various issues with unpredictable results associated with RDP when installing or managing SEP or SEPM. To avoid these, it is best to install or manage SEP or SEPM locally. If that is not possible you can:
      • Use pcAnywhere
      • Use the switch that Microsoft recommends to shadow a console session within an RDP session.
        Note: A Windows Server 2003 server must be configured to permit remote control

        For reference, read the Microsoft article: How to Connect to and Shadow the Console Session with Windows Server 2003 Terminal Services
        http://support.microsoft.com/kb/278845

    Verify the version of PHP that SEPM is using
    Running multiple versions of PHP installed and used by different software products may cause conflicts. PHP performs a check for global configuration (php.ini) in a variety of locations. It forces each product to use its own interpreter which allows the product to operate properly and to use the correct version of PHP associated with each product.

    To check if there is a version conflict with the version of PHP that SEPM is using:
      1. Open a blank document with a text editor (Notepad for example.)
      2. Copy/paste the following code into the document:

        <?phpinfo();?>
      3. Save the document as phpinfo.php in the folder C:\Program Files\Symantec\Symantec Endpoint Protection Manager\PHP
      4. Click Start > Run
      5. In the Open box type:  cmd
      6. In the command window type:

        cd "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\PHP"
        php phpinfo.php | more

        If you see text output to the screen that displays the status of PHP, then PHP is installed.
      7. Confirm that this is the correct version by:
        • comparing it to the version of the file: "C:\Program Files\Symantec\Symantec Endpoint Protection Manager\PHP\php.exe".
          The version displayed by the php command and the version of the file should match.
        • See the line in the output text on screen that says Loaded Configuration File =>
          This is the configuration file the installed version of PHP is using. Ideally, this file will be: C:\Program Files\Symantec\Symantec Endpoint Protection Manager\PHP\Php.ini
      8. If you see text that says: " 'php' is not recognized as an internal or external command", then the PHP installation for SEPM is broken. In this case, do the following:
        1. Close the command prompt.
        2. Copy the file 'phpinfo.php' to C:\
        3. Click Start > Run. Type cmd
        4. In the command window type: php phpinfo.php | more
          • If the command returns: " 'php' is not recognized as an internal or external command", then PHP is not installed and registered with the OS. the problem is not with SEPM as long as step 6 produced a result.
          • If the command returns a status of PHP, then PHP is installed and registered with the operating system. If the version displayed here does not match the version installed with SEPM (step 7), then there is a problem (version mismatch).
        5. Close the command prompt.
        6. Copy the 'phpinfo.php' file to: C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting
        7. Open the web browser to: http://LocalHost/Reporting/phpinfo.php. A browser page describing the PHP status should display. If a 404 page "Page not found" displays, turn your troubleshooting to IIS.

      Resolving a PHP version conflict with SEPM

      If you do find a PHP version conflict, read the article: Specifying the php.ini file used by the Symantec Endpoint Protection Manager (SEPM) Reporting website at http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008060213161448

      If this article does not work try the following workaround. Be advised that any application depending on the PHP version different from the PHP version used by SEPM may be disabled or broken.

        1. Make a back up of the PHP folder that is not the SEPM version. Call this folder A.
        2. Copy the contents of the PHP folder C:\Program Files\Symantec\Symantec Endpoint Protection Manager\PHP to folder A (overwriting any and all files)
        3. Restart the SEPM service. A restart of the entire computer may be needed.

    Uninstall/Reinstall the SEPM
    If it proves necessary to uninstall and reinstall the SEPM, follow the instructions in the following articles: Warm regards,
    Sumit Bose


  • 6.  RE: SEPM "Unable to communicate with the reporting component" on SQL database

    Posted Sep 04, 2009 09:31 AM
    Hi Sumit,

    I appreciate your participation in the troubleshooting process. But a point to be considered:

    If you are copying from a document, then please post the most relevent step that you feel should work in this case.
    Otherwise, if you feel that complete document is necessary, then, a link to the document will suffice as well.

    Best,
    Aniket


  • 7.  RE: SEPM "Unable to communicate with the reporting component" on SQL database
    Best Answer

    Posted Sep 30, 2009 01:37 PM
    Hi I try all your recomendation. After I decided open a case in Symantec Support and the solution was:
    in the folder program files\symantec\symantec endpoint protection manager\ php.ini
    put these lines in ON :
    display_errors = Off
    display_startup_errors = Off

    login in the reporting site by IIS manager and there appears the error.  The error was by 2 missed files in the folder Program Files \Symantec\Symantec Endpoint Protection Manager\Inetpub\Reporting\Resources
    reporter.php
    reporter2.php
    I copied these file from another SEPM and re run the server configuration wizard again!

    Ready all is working now.
    Regards


  • 8.  RE: SEPM "Unable to communicate with the reporting component" on SQL database

    Posted Oct 09, 2009 07:01 PM
    This was a major PIA to get working.

    I initially set up the SEP5 database on a remote SQL Server 2005 system and used a domain account created specifically for SEP usage.  This same domain account, during the SEPM install was used to connect to the DB (which it did just fine).  However the reporting component wouldn't work upon starting SEPM.

    In IIS I would get an "access denied" error message when trying to browse to the Reporting folder.  By design the domain account I had used during setup had permissions to this vFolder.  Upon starting up SEPM and getting the reporting component error I would simultaneoulsy note an error in the Event Access log on the SQL Server indicating that the login was denied access to the DB.

    I ended up creating a symantec specific SQL Server account and re-ran the SEPM config wizard using the SQL Server account instead of the domain account (tested ok via the ODBC tool).  I then changed the SEPM server's local  IUSR_SERVERNAME password and replaced the IIS permissions of the Symantec website and sub compents to the IUSER_SERVERNAME account and with the updated password.  I then confirmed that in IIS I could browse to the Reporting page at which point I got the expected login.

    After restarting IIS and SEPM and then logging in I no longer received the reporting component error.