Hi,
I am getting below error message while logging on to Deski/Designer.
Cannot access the repository. (U5R0013)
[repofiroxy 13] SessionFacade::open5essionLogon with user info has
Failed(Transport error: Communication failure.(FWM 00001)
(hr=#0x80042a01)
I have already included the CMS server’s name and IP in Host file. Telnet is also working for the CMS port 6400.
Any suggestions?
nicholas (BOB member since 2008-07-31)
Hi all,
We have the exact same error.
Users who can’t log in are on a different network/domain - all other users on internal network can log in fine.
Accessing through DeskI and using BOXI R3 on Oracle - server is Windows 2003.
I’m really not sure where to look, can anybody help/provide some pointers?
Kind regards,
leroyb
leroyb (BOB member since 2004-02-16)
We had this issue after moving to a new Win2008 server, and it was sort of a DNS issue… We had to have our server registry changed to handle the long kerberos values (basically, was not able to read the authentication path). Our network guys helped fix this, and then we started getting the right DNS lookup.
Verify you can ping your server with the fully qualified domain name from this box, then make sure you don’t have any firewall restrictions.
Any other info you can share would be helpful,
Brent
bdouglas 
(BOB member since 2002-08-29)
Thanks for that.
I was leaning towards a network/firewall issue so I’m happy to read that’s how you resolved your issue.
Just to confirm - the only way the users are accessing the system is through DeskI, not a URL.
The users can ping the target server with Fully Qualified Domain Name - specifying a port or not (port 6400)
There has been a test with firewalls turned off and the error was still occuring.
I saw somewhere else that this may be resolved by adding a new entry into the HOSTS file (in %SystemRoot%\system32\drivers\etc); this doesn’t really apply here because the users have tried both with the IP address and with the full domain (and with port and without port specified).
Your solution is a new one so I will have a look at that (although no clue where to change the registry settings and what have you 
Thanks very much,
leroyb
leroyb (BOB member since 2004-02-16)
The connect port of CMS is 6400. However, by default CMS replies on random port, which could be blocked over firewall. You may have your BO admin assign a port to the cms from CMC. under Request Port section and restart it to take effect.
This test would only make sense if you are able to connect to the cms from at least the server itself. other things which i have observed are BO running on multi NICs. You may try to bind it with one ip and test.
BI Thinker
[ http://bi-thinkers.blogspot.com]
BI Thinker (BOB member since 2011-05-16)
Also, if you have a cluster, you may be trying to connect to a service running on a different box - your firewall test may be missing something.
Using IP in your ‘server’ box during login won’t help avoid the DNS issue we had - still goes back to the DNS name…
Google DNS and Kerberos issues, may get you on the right path… Here is what our guy told us.
Good luck!
B
bdouglas (BOB member since 2002-08-29)
Thanks again - this is useful information.
In this particular case, I don’t know if they a cluster of servers (I will have to find out) but I do know that the users who can’t access are members of one and only one group. The setup is relatively straightforward and pretty much out-of-the-box installation.
I’m reading through the admin guide just now - chapter 4, working with firewalls - and I think I am finding lots of useful information in there, specifically when it comes to specifying the ports etc.
When I do resolve the issue, I will make sure to post an update here.
Cheers,
leroyb
leroyb (BOB member since 2004-02-16)
If you do a search here for designer and firewall and me as an author, I remember posting a lot of my setup at the CMC to force ports, for several of the services (filestore, adaptive, etc)… It’s a little tricky.
Post whatever you find, and good luck -
B
bdouglas (BOB member since 2002-08-29)
In my case, it resolved after I open the Connection Server port on firewall.
You need to un-check the option ‘Auto Assign’ next to Request Port in CMC > CMS/IFRS/OFRS/Connection Server properties. 
nicholas (BOB member since 2008-07-31)
Hi all,
Running BOXI R3 on Windows Server 2003, with Oracle DB
I still can’t resolve the issue (FWM 00001 - Connectivity) despite having tried quite a number of possible solutions:
From client site, the user can ping and telnet into the IP address at port 6400 - so I would think that the firewall is letting it all through and that can’t be the issue? In addition, the firewall is ‘open’ for the client’s IP address.
However, the user can not reach InfoView using the short or long name of the server - I would have thought that with the firewall open, they would have at least been able to get to Infoview.
Not too sure where to proceed from here - some have suggested DNS issues, error FWM 00001, but I’m unsure what to do to fix this?
Others have suggested cleaning the cluster information - "Transport error: Communication failure" (cluster) - again, since we don’t have a cluster, I fail to understand how this would change anything.
Any suggestions?
leroyb
leroyb (BOB member since 2004-02-16)
Try those same tests using the fully qualified DNS name of the server, make sure that’s what you have set up in your HOSTS file… If you drop to DOS anc ping the server (full name), do you get the right IP??
What’s the exact error you get?
Have you looked in the registry of this client, any old server information cached there (server name(s))? BO wants to use / cache that after the first time in.
IP tests won’t help here, BO always refers back to the DNS name.
B
bdouglas (BOB member since 2002-08-29)
Hi bdouglas,
thanks for your answer.
The client is getting various error messages now depending on the system name entered.
[IPADDRESS]:6400 -[repo_proxy 13] SessionFacade::openSessionLogon with user info has failed(CMS host ‘[IPADDRESS].6400’ cannot be found on the network. Please verify the name and that network name resolution is working properly.
(hr=#0x80042a01)
FYI, added entry into registry (there was none beforehand) in the format
key = @[SERVERNAME] with value = [FQDN] in the ‘folder’ CMSClusterMembers
In HOSTS file, I have added [IPADDRESS] with [FQDN] - previously there was [IPADDRESS] with [SERVERNAME]
leroyb
leroyb (BOB member since 2004-02-16)
I would ping your short and long server names, make sure those match up… Then I’d remove anything from the registry you have about the cluster / members - those 2 messages about the locally cached version make me think it does not like those.
Do you need the local hosts entries to hit your server? Is the box not in DNS as something?
B
bdouglas (BOB member since 2002-08-29)
hi bdouglas,
I asked the off site / off domain user to ping and tracert
ping a [SERVERNAME] >> c:\testresults.txt
ping a [FQDN] >> c:\testresults.txt
tracert h 20 [SERVERNAME] >> c:\testresults.txt
tracert h 20 [FQDN] >> c:\testresults.txt
When using just the machine name, the results are:
Reply from [IPADDRESS]: bytes=32 time=5ms TTL=122
Reply from [IPADDRESS]: bytes=32 time=4ms TTL=122
Reply from [IPADDRESS]: bytes=32 time=5ms TTL=122
Reply from [IPADDRESS]: bytes=32 time=6ms TTL=122
Ping statistics for [IPADDRESS]:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 6ms, Average = 5ms
AND
Tracing route to [FQDN] [IPADDRESS]
over a maximum of 20 hops:
1 1 ms 1 ms 1 ms xx.xxx.xx.xxx
2 10 ms 4 ms 6 ms xx.xxx.xxx.xx
3 * * * Request timed out.
4 6 ms 6 ms 6 ms xx.xxx.xxx.xx
5 5 ms 5 ms 7 ms xx.xxx.xxx.xxx
6 6 ms 6 ms 7 ms [FQDN] [IPADDRESS]
Trace complete.
The IP address does match in all cases.
When pinging from the server itself, then the IP addresses also match up.
Not sure why there is a request timed out in the middle (when I guess it went from one network to the other).
Anyway, I haven’t tried yet to remove the auto-assignment of ports for the servers, so I guess I will have to do that and specify some ports for the relevant servers and restart the lot - and then also ensure the firewall is open for those ports (I have been told that the firewall is completely open for request coming from the off-domain-user’s IP address/range; which is why I have really given much thought to the port assignment since it should not make any difference.)
Cheers,
leroyb
leroyb (BOB member since 2004-02-16)
I would try this - get your client to add the suffix to his/her DNS setup and try that first ping again (eg, add whatever the difference between the shortname and FQDN). That’s all setup under network, tcpip properties, DNS, suffixes - you might want to do same on your PC and give instructions to your user, there are a few steps to this. That has helped me on other issues…
Sorry, I am not sure I know this answer - are you running on a clustered BO setup?? Do you have any of your services running on a box besides the one you’re pinging, the one you know firewall stuff about?
That caught me before, the filestore servers were behind the firewall, and that was killing client apps - the thread on Designer and firewall has good info on what you need to check.
The timeout in your trace is normal - I think firewall devices, switches, routers don’t report themselves in a trace.
Good luck!
B
bdouglas (BOB member since 2002-08-29)
Hi,
Small update for people getting this error too …
It turns out that it was the firewall after all, but not the one protecting the network on which the BOXI server resides, it was the firewall protecting the network on which the client PC resides and we finally got the external site to update their firewall rules and allow traffic on ports 6401, 6402, 6403, 6404 and also
8443 TCP Tomcat Redirect
8080 TCP Tomcat Connection / ASADMINPort
8005 TCP Tomcat Shut Down
6420 TCP Client Auditing
6410 TCP - Server Intelligent Agent (SIA) / CADPort
6400 TCP - CMS Incoming / NS Port
1566 TCP - Infoview Incoming
and it now works! (port 6400 was already open)
so, to recap … the network in which the BOXI server resides was also protected by a firewall but the firewall rules for that network did allow communications on all ports (from that IP to that IP) - it was the firewall for thr network in which the ‘off-site’ client resides that only allowed traffic on port 6400 (to and fro) - so opening the additional ports solved that issue.
Two other external sites on different network than the first one also have the issue, at this stage I can only assume that the solution we implemented will also work for them.
Obviously we had to untick the ‘auto-assign’ box and specify fixed port numbers for the key servers for it to work (no point opening some ports whilst the comms take place on other random ports).
However … not everything is working … Infoview works fine but DeskI is not playing ball just yet with a new error message (DA0005 - DBDriver failed to load) … but that’s most likely totally unrelated to the issue described in this topic! at least we are a few steps further.
Thanks for your answers,
Cheers,
leroyb
leroyb (BOB member since 2004-02-16)