Please try updating the Windows host file with the Server name and the FQDN and the IP address of both the Servers A and B
<IP> <FQDN> <Server Name>
Also check the DNS also
Many thanks for the reply Nowshad,
but these entries are already present in Host files of both servers.
but format is little bit different.
in host file it is mentioned in following way,
<IP> <Server Name> <FQDN>
Is this make difference?
Also, as I am able to get Workspace/HSS login page using "Localhost"
I have also tried
127.0.0.1 <Server Name> <FQDN>
But no luck.
Yes the format does not make change. Please check the DNS for both the servers
Are you able to ping the serverA using FQDN from Server B? You will have to get ping working first because if ping does not work,then it means that there is issue in the network itself.
Yes I am able to ping "FQDN of server A" from "Server B" and, "FQDN of server B" from "Server A".
Also I can able to get login page using FQDN on server B, though Shared service is on Server A.
But I cant get workspace/HSS login page, on Server A itself if I used FQDN in URL.
I get error:-"Internet Explorer cannot display the webpage"
I am using IE8.
I believe this could mostly because of network/DNS configuration, if its not the issue with "hosts" file.
Check whether the server is having multiple adapters(NIC cards) being enabled.
My advice would be to see what /*is*/ happening before even going to the stage of editing the host file etc. If it's not a name resolution issue then editing the hosts file isn't going to help and if IP addresses change at some point in the future then things are going to break If you suspect name resolution then you should try running 'nslookup FQDN' first to make sure that the IP being returned from DNS is the correct one. If you know the IP address you could also try ping -a x.x.x.x to do a reverse lookup (i.e. try to convert IP address back to FQDN).
Seeing as browsers these days seem to insist on hiding HTTP status codes that might give some clues (because it might confuse end user or /*shock horror*/ even give them clues about the problem) and you're getting the über generic and supremely unhelpful "Internet Explorer cannot display the webpage" I'd want to see what is actually coming back as a response to your request when you see this error. To look 'under the hood' you could always use the Fiddler free web debugging proxy to see what is coming back as a response to the failed HTTP(s) request. Fiddler can often show problems at a lower level than you'd see in the browser and is a very useful tool in anyone's troubleshooting arsenal.
Once you know what /*is*/ happening you'll have a better idea on corrective steps to take