PM10.10 unable to connect to Web Ports: 80, 8080, 8081

I am hoping that one of you can help me figure out why this connection is failing. I have recently attempted to update our existing Policy Manager 10.01 server to the newer 10.10 version.

But after the installation completes succesfully, the PM console on the server is unable to connect, reporting that the service is unavailble for localhost.

Loocking at the server status screen I can see that it is unable to connect to ports 8080, 80 and 8081 fo r the various modules.

PM 10.01 has no issue here and reports the connections are green and good.

The server that PM is on is also an internal web serving servicing several information screens around the school, but its service runs on other ports and has never been an issue before.

I am looking for some helps\tips on figuring out why PM 10.10 is not connecting as it should.

Find more posts tagged with

Comments

jackma

Hi,

you are able to change ports after installation, using the regedit tool.

After changing the registry values, you need to restart the "F-Secure Policy Manager Server" service.

On 64bit systems, the registry folder will be HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\<company>\<product> sub key.

Now let us say you have Host port "80", but your clients are already pointing to port 80 to communicate with the Policy Manager server you will have to:

1. Edit the "Management Server URL" to the new value on "Root" level of your policy domain, since basically all your products will connect to the same server. example: before = http://myserver.local - after = http://myserver.local:81

It is important to not forget the ":portnumber" behind your URL.

2. Set that value to "FINAL" - you need to close the lock next to that value.

3. Make sure all clients will in fact inherit that falue. You can right click anywhere in the wording "management server URL" and set "force value" or at least check on "show domain values" to see íf there are any subfolders or hosts not actually inheriting the "Root" value you are setting.

4. You distribute the policy.

5. Now you have to wait. There is no way to anticipate when all 100% of your clients have the new value measured in "time". You can however check the "Status" pane and go to the "central management". There you will see if clients have the "latetest" policy. Better: you display the "policy counter" on the client and server. You need to right click the grey category bar to actually display those two extra columns.

6. When you are sure all clients have this new policy, then you can change the Host port of the Policy Manager server to the new value.

Note: Of course when you give a client a not yet used Host port then they will do a fallback to the last known good connection. That is why they are still communicating with the same port you are trying to get away from.

7. You change the host port in the registry and restart the Policy Manager Server service.

8. Now, again after "time" , be patient here, your clients will have no other choice to connect to the new port, since now the old port does not work. But clients will ONLY connect to the new port , if they were in fact able to get the policy where you changed to management server url in the first place. If you have computers that were offline / powered down for weeks now, then they will not find the server on the new port, because the time (step 4.) when you distributed the new policy they were not there to fetch it and were not there weeks afterwards. This is why it is crucial to verify the clients in step 5.

Costas-Inter

I finally figured out it was the World Wide Web Publishing Service, even though I couldn't tell by netstat that it was using or listening on port 80. I disabled that service and I was able to get back into the Policy Manager. In order to change the ports and keep my clients connected, I changed the port back to 80 and tried to distribute a policy telling the clients to use 85. That did not work. The policies would not update.

This part needed a bit more 'care' I think and it should work. When you sent a policy to client to change the port of communication, make sure that it is locked setting. And when the workstation receives it, tries to connect to port 85. Port 85 is not availeble and thus reverts back (tempoarirly) in using the old good known settings (safety mechanism in case you 'redirect' your workstation to dummy PMS). But periodically it will still try the new communication settigns, and once it finds response it will start using those.
I know that it is not trivial, but with a bit plannig and test can be done.

Regarding the ports, I know that if defaults ports change to non standard http ports, then the 'firewall'-ed guys will start complaining...

The installation wizard allows to change the settings, so a good planning ahead on what else you might install on this machine, and testing each step of installation if it went OK, keeps you out of trouble.

My humble opinion...

Costas

tylerhen

I had this same problem. Major screw up on F-Secure to be using these ports. I paid for Premium Support and they wouldn't even help me figure out what the problem was.

They told me to change the ports for Policy Manager and then none of course none of my clients or servers could connect then. They were not helpful with this either.

So I've had to leave the WWW Publishing service turned off and leave the ports on 80, 8081, and 8080. Otherwise I would have had to reinstall to all clients, or manually change the port on all clients. Unbelievable.

Policy Manager is turning out to be pretty buggy.

etomcat

Hello,

I do not know why port 80, 8080, 8081 are the defaults in FSPM, as they are certainly not the recommended settings! F-Secure education PowerPoints usually show ports 85, 8085 and 8086 used for installation.

The thing is, TCP ports 80 and 8080 are usually occupied by IIS on Windows or Apache web server on Linux, making them unavailable for FSPM. Even if those ports are free as of now, it is better not to install on them. What if your boss decides next month that you must place Exchange on the same server? That needs IIS, meaning FSPM would be in the way, necessitating the reinstallation of central management and the FSAV clients.

I really don't buy the story that potential routing problems are the reason FSPM installer keeps the defaults at ports 80, 8080, 8081. Modifications for ports 85... are not that difficult in the gateway level firewalls.

Sincerely: Tamas Feher, Hungary.

KG-Admin

Oh - forgot to state that installing with defualt settings and keeping the existing settings of the server.