Try this steps & let me know?

Login:

On the Login tab the User ID and Password should be entered and valid.

The default user name for the embedded database is DBA

Database server name

The information required here can vary by environment.

Try all of the following until you find one that is successful:

Leave the entry blank (this is the default for the embedded database)

Machine Name

localhost

127.0.0.1 (the local IP)

IP address (ex. 10.0.0.1)

Fully qualified domain name (ex. server.mycompany.com)

To test each of the above, click the ODBC tab, then click Test Connection. It will return Connection successful once the configuration is correct.

On the Login tab the User ID and Password should be entered and valid.

The default user name for the embedded database is DBA

On your server go to Internet explorer & type in

Http://localhost:8014/reporting 

do you get a blue login screen if yes then try to log in using your login account for the SEPM dont put in anything in the domain part.

Hi,

       Please try the following and let us know whether it helped.

Click on Start> Run ，type services.msc ，click Ok

Stop the "Symantec Embedded Database" Service.

Browse to: C:\Program Files\Symantec\Symantec Endpoint Protection Manager\ASA\win32\ , double-click on dbsrv9.exe to launch the application,.

Click the ‘Browse’ button to point to sem5.db which Symantec Endpoint Protection Manager using. (Note: Please attention, there is a sem5.db in <SEPM>\ASA\win32 folder, DO NOT select this file!)

In ‘Server name’ , input your computer name , and click ‘OK’ to start

From the Control Panel open Administrator Tools, double click Data Sources (ODBC).

Choose the System DSN tab, double-click SymantecEndpointSecurityDSN.

Choose Network tab, uncheck ‘Share memory’ and check the ‘Named pipes’

Choose Database tab, input your computer name.

Choose Login, input User ID as dba and pasword of your DBA.
NOTE:  The password is the Database administrator password created during "advanced" installation.   If a "typical" installation was selected the password will be the original password created during installation.

Leave the defaults for the rest of the items and click Finish

Click the Test Data Source on the next page and ensure it states "Success"

Click OK

 Error when it reached the 3rd tab of ODBC..make sure you have entered the SEPM server name correctly..do not put IP over there..name should be just hostname and not the FQDN.

on the 2nd Tab username put DBA and in password put the initial password that you gave to SEPM login at the time of SEPM install.

Nothing was working, so I ran the 'Management Server Configuration Wizard' which sets the password on the database.
On the 'Login' tab, I put in 'DBA' for the 'User ID' and put in the password (this had previously been blank)
On the 'Database' tab, I put in the server name by 'Server name:' (this had previously been blank)
On the 'ODBC' tab, I click 'Test Connection' and got 'Connection successful' !!!

However, I am still getting "Unable to communicate with the reporting component" when I open SEPM console.  Help!!!

On your server go to Internet explorer & type in

Http://localhost:8014/reporting 

do you get a blue login screen if yes then try to log in using your login account for the SEPM dont put in anything in the domain part.

If your Embedded database service is still stopped then you should not be able to log in to the SEPM.

Its starange that you are able to login.:) with reporting component error.

check this document

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2008042212582048

What is the OS on the machine where SEPM is installed ?

If it is XP then follow the  steps:

http://service1.symantec.com/SUPPORT/ent-security....

SEPM is installed on Server 2003 Std SP2
 

Try to change the Iusr account with any other user account & see if that helps. for Symantec Web server under the IIS.

Please run IIS Diagnostics Toolkit

http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=9bfa49bc-376b-4a54-95aa-73c9156706e7&displaylang=en

Reset the password for IUSR account

Also make sure that Inder Local security policy Guest  is not under  denied acess.
and access this computer from the network is enabled

Can you try to repair your SEPM Installation

try to resintall IIS hope it will help you to resolve the issue, I have resolve this issue by doing reinstalling the IIS

 NO...no need to re-install SEPM if you re-install IIS.

Un-install IIS--reboot the server..
Re-install IIS-Reboot the server then Repair SEPM from add/Remove programs

add/remove programs - Syamntec Endpoint Protection Manager-Change-Repair..

I uninstalled and reinstalled IIS and repaired SEPM.  However, I am still getting "Unable to communicate with the reporting component" when I open SEPM console.

At least the SEPM service is back to running.

Hi Drew,

It seems that a lot of work has been done on this particular thread, Please bare with me as I am going to ask you to perfom some steps which would sound repetive to you.

Note : - Whenever you get the error "Unable to communicate with reporting component" the very first thing to do is go to IIS and expand the website hosting Symantec web server and browse reporting.

Steps to perform

1. Browse reporting from IIS.
2. Which you give you either of the two results.
3. Frist, it might open up with the reporting login page.
4. Second, it might give you unexpected server error.

Scenario 1: Login Page.

In this case you need to check the ODBC data source connectivity which you have already done so that is not the issue.

Scenario 2: Unexpected server error.
Our developers have designed this pages for specific error which you get in IIS. In order to find the IIS specific error you have to create a virtual directory for reporting follow the link below in order to do so.
https://www-secure.symantec.com/connect/articles/how-create-new-reporting-virtual-directory-iis-manager-troubleshooting-unable-communicate-r

Once the virtual directory is created browse the same virtual directory and you will find the error code at the end of the page.
For example: 

401.1 Unauthorized acces.
401.3 ACL
403 Access forbidden.

Once you get the error code try to search symantec article to solve those issues as there are many documents which address the issues which are mentioned above.

Kindly let us know if you have any queries on the above mentioned post.

Hope it helps.

Regards,

Can u try by repairing your installation. For repairing you have to go to add/remove programs in control panel . Then select Symantec endpoint protection manager click on change. It will open one wizard, in first screen click next, in second screen u will get a repair option.

ARe u logged in locally to the box or remote desktop /rdp?

The problem is with the IUSR account..

create a new user in AD, make him member of users. (you can put your currrect logged in credentials, if its DC, iis iusr account should be of domin\user format)

put in IIS
right click on symantec web server directory
right click reporting, click on browse,

see what you get.

log on prompt?

Would the IIS Diagnostics Toolkit help?  I have it installed, but I need help using it.

Just want to share the experienced I had with regard to the error we're talking about.."unable to communicate with the reporting component"

The main cause of mine is "Incorrect permissions set for the Symantec Endpoint Protection Manager folder."

Below is the troubleshooting steps I did..

1. You repaired the installation of the manager and that did not resolve the issue.
2. We tried to browse the reporting page in the IIS and got the error "Access is denied"
3. In the IIS logs it showed as http 401 1 error which is with regards to access denial.
4. Set the appropriate permission in the IIS for the Symantec Webserver and did not resolve the issue.
5. Renamed the IUSR_ account and restarted the IIS services and still the issue did not get resolved.
6. Gave the Everyone group full access to the Symantec Endpoint Protection Manager folder in the C: drive and restarted the Symantec Endpoint Protection Manager service and was able to see the reporting page in the IIS.
7. Logged in to the manager and it was successful.
8. In a while all the clients started communicating with the manager.

reference:

http://service1.symantec.com/SUPPORT/ent-security....

http://service1.symantec.com/SUPPORT/ent-security....

hope this helps..

Optimus, I did what you said:

• Gave Everyone Full Control over the "C:\Program Files\Symantec\Symantec Endpoint Protection Manager" tree
• Reset IIS using iisreset
• Restarted the Symantec Embedded Database and Symantec Endpoint Protection Manager services

I am still getting "Unable to communicate with the reporting component" when I open SEPM console.

I am logged on remotely via RDP...this server is at a client's site and not one that I can easily get to locally.  Does it matter?

Would the IIS Diagnostics Toolkit help?  I have it installed, but I need help using it.

 

Check the Scm server 0.log under C:\Program files\symantec\Symantec Endpoint Protection manager\Tomact logs

See if its showing you Http 401 error?

Does anyone know how to use the IIS Diagnostics Toolkit?
I have a Server 2003 with SEPM 11.0.4202_MR4_MP2 installed in it's own web site, Symantec Web Server (not the Default Web Site).

When I run IIS Diagnostics (32bit), Auth Diagnostics, how do I change the "Site:" from "http://localhost" to the Symantec web site?  What is the Symantec web site?

Hi Drew,

I think if you need to solve this concern asap. Try to contact Symantec Support so he can assist you thru web-ex for fast resolution.

regards

I understand you drew at NF. A program should not cause problems like that. As a network admin I still could not solve same problem. Ive read and checked Symantec`s help pages and followed all instructions no chance. I am about to give up and look for different solutions instead of Symantec End Point.

By the way whos that hideki_nakatani? I ddi not login with that account? Is it a kind of public account?

Hi Drew,

Under C:\windows\system32\logfiles look for w3svc folder associated with symantec web server, open the latest file and at the end of line you would find an error e.g. 401 3 64

Kindly paste that error.

Regards,

Try this steps

Verify PHP information

1. Create a text file with the following line:

<?phpinfo();?>

2. Save the file to the desktop as test.php

3. Copy test.php to the Php folder within the Symantec Endpoint Protection root directory.

Default path: C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Php

4. Open a command prompt (Click Start, then Run. Type CMD, then click OK).

5. At the prompt type cd followed by the path to the PHP folder

Example: C:\>cd C:\Program Files\Symantec\Symantec Endpoint Protection\Php

6. Once in the Php directory, at the command prompt type:

php.exe test.php > result.doc

7.Navigate to the Php directory, there will be a file called result.doc. Open that file and check the information provided to ensure Php is configured correctly.

Things to check:

1. PHP Version should be 5.2.4 or higher.

Ex. phpinfo()PHP Version => 5.2.4

2. The configuration file (php.ini) should be located within the Php directory of the Endpoint Manager

Ex. Configuration File => C:\Program Files\Symantec\Symantec Endpoint Protection Manager\Php\Php.ini

If the incorrect php.ini file is in use:

Once it is determined that using the incorrect Php.ini is the issue please use the following document to specifiy the Php.ini to be used by the SEPM:

Specifying the php.ini file used by the Symantec Endpoint Protection Manager (SEPM) Reporting website

Find the file reported above and change the name from php.ini to php.ini.bak.

Run the command to check phpinfo again and check the path to the configuration file, keep performing step 1 until the path is correct.

Once the path and version are correct PHP should be functioning properly. Confirm by opening the Endpoint Manager.

I went to do what Nirav Mistry asked and noticed that the IIS logging had stopped.  I looked in the Event logs and found this entry:

Event Type: Warning
Event Source: IISADMIN
Event Category: None
Event ID: 105
Date:  8/27/2009
Time:  6:15:21 AM
User:  N/A
Computer: HKAFS
Description:
IISADMIN service failed to verify anonymous/wam account HKA\IUSRB_HKAFS.  Some IIS functions can fail for this reason.

Almost 3 days ago (see the post above at that time), I had switched from the IUSR account to one I created: IUSRB.  So just now I reset the password for account IUSR, changed IIS back to IUSR, set the password in IIS, and did a iisreset.  I am still getting the above error.

Unfortunately, I am not an IIS expert.  Does anyone know what I should do to fix this?  I really do appreciate all the help I have gotten so far.

hii
drew

If all solution is not working please uninstall and reinstall IIS........

I done with this today on my UAT.......

:)

Uninstalled and reinstalled IIS, ran a repair on Symantec Endpoint Protection Manager.  Event ID 105 is now gone.

However, the IIS logs are not being written to (IIS logging is turned on). I am still getting "Unable to communicate with the reporting component" when I open SEPM console.

Plese check network services and local services are add in IIS or not........

Where in IIS do I check that?

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

Also conform which OS and SP u using and which DB .......? MS SQL 2005 .......?

You can chec kthat under the IIS > Application pool > Default App pool > Propertis > Identity tab & see if there is network service or local system.

Drew
did you tried that PHP test that I have mentioned?

I got to go home so this will be short and sweet.  Symantec Support had me do lots of stuff...which I had already done based on the valuable comments from this forum (thank you so much!).  What got it working was to set the "Administrator" account as the anonymous access account in IIS for both web sites: the Default Web Site and the Symantec Web Server.

Now it works but anyone who can get to the web site will have administrative access to the server!  Can anyone tell me what potential security problems that this might cause?

The Symantec Support Case Number is 281755991

If you check this thread I have suggested you this around 6 days back.
You can try to create a new user instead of admin try to use that user????

if Admin is working the there is some permission issues with the Iusr account.

but I am not sure if this will give you any security threat. I think it should not.:)

...in a million years considered using the actual "Administrator" account (the account with God-like access to the entire system, the only account that cannot be disabled or locked out if someone tries to use it to gain unathorized access) in this way.

Yes, it is now working.  But at what risk?

Well since it is a new account you can try removing it from admin group..let it be part of domain users and guest.

Manually set permission of this user ( IUSRB_... )
to /program files/Symantec Endpoint Protection Manager
/docs and Set/all user/app.. data/symantec/Symantec Endpoint Protectio Manager

also remember to go to advanced and check "replace permission entries on all child objects....."

Here is what I did:

1. In Active Directory Users and Computers, I created a new user account: IUSRC_<COMPUTERNAME> and made it member of the Domain Users and Guest groups
2. In IIS on  "Default Web Site", set <DOMAINNAME>\IUSRC_<COMPUTERNAME> as the anonymous user account and set the password
3. In IIS on the "Symantec Web Server" site, did the same as Step 2
4. In IIS on "Web Sites", did the same as Step 2 and allowed it to propagate to the two sites
5. Since this machine is an Active Directory domain controller, I edited the Default Domain Controllers policy, drilled down to Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ User Rights Assignment, and added <DOMAINNAME>\IUSR_<COMPUTERNAME> to "Access this computer from the network", "Adjust memory quotas for a process", "Logon as a batch job", and "Replace a process level token".  Yesterday, Symantec Support had already had me add Authenticated Users, <DOMAINNAME>\IWAM_<COMPUTERNAME>, <COMPUTERNAME>\Administrator, <COMPUTERNAME>\IUSR_<COMPUTERNAME>, <COMPUTERNAME>\IWAM_<COMPUTERNAME>, LOCAL SERVICE, and NETWORK SERVICE to those policies.
6. Opened a command prompt and typed "gpupdate /force"
7. Opened Security on "C:\Program Files\Symantec\Symantec Endpoint Protection Manager".  Added <DOMAINNAME>\IUSR_<COMPUTERNAME> and gave it Full Control.  Symantec Support had already had me give Full Controll to Authenticated Users, <DOMAINNAME>\IWAM_<COMPUTERNAME>, <COMPUTERNAME>\Administrator, <COMPUTERNAME>\IUSR_<COMPUTERNAME>, <COMPUTERNAME>\IWAM_<COMPUTERNAME>, LOCAL SERVICE, and NETWORK SERVICE...SYSTEM and <DOMAINNAME>\Administrators were already there with Full Control.  Clicked on Advanced and selected "Replace permission entries on all child objects..."
8. Restarted the IIS Admin Service which also restared the Symantec Endpoint Protection Manager, World Wide Web Publishing Service, and HTTP SSL services
9. Ran iisreset

Ran SEPM console and got the same error: "Unable to communicate with the reporting component"

I am now getting Event ID 105 in the Application Log: IISADMIN service failed to verify anonymous/wam account <DOMAINNAME>\IUSRC_<COMPUTERNAME>.  Some IIS functions can fail for this reason.

What did I miss above?

Drew,

I had same problem.  First was unable to connect and second was the dreaded 'unable to communicate...'. 

Checking Enable Anonymous Access block for my IUSR fixed my connect problem and Removing IUSR from my Guest group fixed "Unable to connect.  Give it a shot if you haven't already.

Oh yea....I was Remote Desktop to Test (Virtual) Server as well.

"Enable Anonymous Access" has always been checked in IIS.

I removed the IUSRC account from the Guest group, did an iisreset, stil does not work.

I had the same issue in few servers..
I tried all the option available in this site but dint work.. Then i took a backup(Database, server.xml, keystore.jks) reinstalled,restored the db and other files. After reconfiguring all are working fine.
 

Let me make sure I get this right before I try it, because I don't want to have to reinstall all the clients (that would not be good with this customer).  How would I do the above?  What is the procedure?  As I started to look for the above files, I notice that there are mutiple files that could fit the descriptions.  Is this one of the files?
"C:\Program Files\Symantec\Symantec Endpoint Protection Manager\db\sem5.db"
Can someone please give me the exact name and path to all the files that I need to backup?  Also, after reinstalling, how do I restore the files?  What files do I need to backup so that I do not have to reinstall all the clients?

Thanks in advance!

The files that you need to back up:

Take the Backup of the db folder from the location \Program Files\Symantec\Symantec Endpoint Protection Manager 

Copy and Save the Server.xml file from the location \Program Files\Symantec\Symantec Endpoint Protection Manager\tomcat\conf

Copy and Save the KeyStore.jks file from the location \Program Files\Symantec\Symantec Endpoint Protection Manager\tomcat\etc

Best Practices for Disaster Recovery with Symantec Endpoint Protection

http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007082112135948

I will try it this evening.

Can you tell me which directories you may have changed?  I know this is a while ago, but I am having same issues.  Everything was OK until I made server a backup DC.  Now nothing works and I have looked at all of these fixes.  Nothing helps.  And on top of this, I tried a reinstall and although I thought I had a good backup, all is lost.  SO I will have to recreate everything, but I still need to get the original issue resolved.

So I started looking around the drive at the NTFS permissions and found that the admin(s) before me had changed some of the permissions of some of the directories from the defaut (not the Symantec ones).  So I reset the permissions to default and now it all works!  Finally!