MSME Access control on each server
<msms install folder>:\bin\sdedit.exe - right click run with admin (start -progs -mcafee - msms - access control)
Make sure your admin credentials are listed in both servers access control as allowed
Local url is http://localhost:45900/PortalShield/
So if you test from remote server/workstation http://<IP Address>:45900/PortalShield/
Does this prompt you for credentials and if you supply the correct credentials does it work??
OR log on as one of the Local Admins in the access control list in WFE2
Right-click iexplorer.exe - run as admin
add http://localhost:45900/PortalShield/ in url bar
Do either of these work ??
but unfortunately no effect
let me be more clear :
- WFE1 (the one which hosts CA) : hotname =wfe1
- WFE2 (the one which does not let its Web UI console to show correctly ) hostname =wfe2
If I log as admin farm, start IE in admin mode i get these result :
- in WFE1 :
- in WFE2:
- http://localhost:45900/PortalShield/ : failed "Either the McAfee® PortalShield™ service is currently not running or you do not have sufficient privileges."
- http://wfe2:45900/PortalShield/ : failed "Either the McAfee® PortalShield™ service is currently not running or you do not have sufficient privileges."
- http://wfe1:45900/PortalShield/ success
- outside WFE1 & WF2 :
When i restarted the WFE2, as cache is empty, requesting http://wfe2:45900/PortalShield/ takes a little bit time more but it shows CORRECTLY (PortalShield/0409/html/Index.html) for a fraction of a second and then basculates to error ("Either the McAfee® PortalShield™ service is currently not running or you do not have sufficient privileges.")
From Sharepoint, i configure antivirus to only scan on upload direction.
the two wfe are behind a round robin load balancer.
When WFE1 is the sollicited one, uploading file works and from the console ( http://wfe1:45900/PortalShield/0409/html/Index.html) i can see the trace of the uploaded file.
When WFE2 is the sollicited one, uploading file works and and i can not see the trace of the uploaded file in the console ( http://wfe1:45900/PortalShield/0409/html/Index.html)
The fact you get the "service is not running" screen suggests access is being denied someheres .... that is actually an xml file from the msms site which is a redirect for inabillity to run or access interface.
Try this - stop MSMS service on WFE2 (ensure safeservice.exe, rpcserv.exe(2), postgres.exe (several) and PsPickerx64Srv.exe all leave task manager.
In <msms install folder>\config renam all the xmls to .old
Access WFE1 - <msms install folder>\config
Copy all the xmls from that folder to <msms install folder>\config on WFE2.
Try start service and access if it fails would be advisable to get a case open in support possible to get debug of service start up and accessing interface
tried it no change !
i noticed that the case where it works (wfe1) a request to dynamicpage.dll is done
whereas no request occurs in wfe2
dynamicpage.dll is localised in C:\Program Files (x86)\McAfee\McAfee PortalShield\ui\cgi-bin\dynamic
i checked permission to that file : it is the same in both case.
may be this can help you...
found it !!
the application pool hosting the web site http://wfe2:45900/PortalShield/ is named MSMSAppPool
The auto generated config file for MSMSAppPool and located in "C:\inetpub\temp\appPools\MSMSAppPool" is missing an element
under <configuration\security\isapiCgiRestriction> section :
<add path="C:\Program Files (x86)\McAfee\McAfee PortalShield\ui\cgi-bin\dynamic\DynamicPage.dll" allowed="true" groupId="PortalShield Extensions" description="PortalShield Extensions" />
this corrects the issue.
for correcting this, top level of IIS :
then add :
path="C:\Program Files (x86)\McAfee\McAfee PortalShield\ui\cgi-bin\dynamic\DynamicPage.dll" allowed="true" groupId="PortalShield Extensions" description="PortalShield Extensions"
Last question is now why "MSMS3.5 Install setup" did not write this in the applicationHost.config ?
With that removed or set "NOT Allowed" I get HTTP Error 401.2 error "invalid authenticaton headers"
This doesn't even allow me to get to the <msms install folder>\ui\<lang>\html\NoConfig.html - which is the "service is not running" page you were getting redirected to.
So was unsure that it was caused by inability to get to anything at all on the site.
To be quite honest never saw before - and that is a great find .... I had a quick look at my install log and I cannot see this being done in MSI - suggests its a call to instalhelper or call to another script or exe. If I can find anything on reason I'll post it here ....