(imported comment written by Rafael Rodriguez)
when it goes to download some files on a Fixlet usually by _BESGather_Comm_UseUrlMoniker. must be configured for that type of communication system using IEM. but this error BESRelay.log file on the central server, I have not been able to find the solution.
(imported comment written by dhtorsdc)
I’m also getting these “http Error 28” timeouts in the console. It’s a new thing with 9.0.649. I’ve had almost nothing but trouble with the version 9 upgrade. I have a ticket in with support, but they’ve gone silent…
(imported comment written by cglimson)
Hi dhtorsdc,
Is there an update from Support about your ticket on this? I’ve been following the thread but not sure if this was resolved.
Thanks!
Regards.
(imported comment written by dhtorsdc)
No solution, just a workaround - which is to add setting _BESData_Comm_TimeoutSeconds to the console machine and set it at a high number. Logs will tell you how long certain operations are taking, so that you can adjust the setting. Mine is currently at 300. I attribute it in part to just plain old bad code and hope that it will be addressed soon by IBM. 8.2 never had this issue, and little changed in the environment I’m working with when I upgraded to 9.
(imported comment written by ItsAvi)
i’m getting this error too, it’s plain annoying, opened a thread and then found this empathy thread 
(imported comment written by TallTomD)
I’m getting a lot of user complaints about these errors in the Console. I’ve got a global deployment with probably 200 operators around the world using RDP to connect my Console Server farm. More and more of them are complaining about these Error 28 http timeout errors.
I’ve also had problems where my Console will shut down, or report an error and give me the option to Ignore or continue.
This all began with version 9. I’ve been running BigFix since version 6, over many years. These errors began almost immediately when I upgraded to version 9.0.649.0
Anybody find a solution?
(imported comment written by bxk)
We’ve been seeing this error a fair bit since we upgraded to 8.2. It’s also seemed to cause us a lot of console data corruption. So much so that we purge all profiles on the RDS servers at 6am. It disallows CO customization, but generally prevents the user from being unable to open the console.
I had hoped that v9 would have given them more time to work out this bugs. 
(imported comment written by KarenKue)
I’m in the process of upgrading to 9.0 ( the task 1435 is currently running), and I’m getting the HTTP Error 28 already.
For those who upgraded to 9.0 using the available tasks, did you faces any issues along the way?
(imported comment written by TallTomD)
My upgrade took almost 6 hours. I called support after about 3 hours, and we waited. We reviewed services, processes, and verified everything was still in progress. I guess it took a lot of time to upgrade the database. Suddenly it moved on to the next step, and everything was OK.
However, there are 3 new issues that came with version 9:
1 - The never ending HTTP Error 28 messages - and the occasional “console error” related to the timeout, which prompts to close or ignore.
2 - Many of the clients running version 9 can no longer determine their hop count to their relay. I’ve got a mixture of 7, 8, and 9 clients reporting to the same relay. My relays are distributed globally, reporting in to a couple top level relays, which then report to my main server. The version 7 and version 8 clients have almost 100% success reporting the hop count. The version 9 clients are maybe 50% successful in reporting the hop count. This throws off my charts and environment health statistics.
3 - There is almost constantly a yellow exclamation mark, counting up all the authentication errors during my Console sessions. These don’t seem to have any impact. The console continues working, but the ever increasing error count doesn’t look good to customers that notice such a thing.
I’m also having trouble using the pass-through credentials option. That doesn’t work if you have a multi-domain forest with trust relationships between the AD domains. It only works for users on the same domain as the main server.
Let me know if you solve the HTTP Error 28. That is very annoying to the users.
Thanks,
Tom
(imported comment written by hosmar)
Any updates on this issue, I just ugraded the server from 8.2 to 9.x and when I open the console I gues this HTTP error.
(imported comment written by jgstew)
You need to increase the value of the setting _BESData_Comm_TimeoutSeconds of the console machines. Try 180 to see if that helps, otherwise try a higher number.
There is a fixlet available here that will do this:
http://bigfix.me/fixlet/details/3676
(imported comment written by hosmar)
Thanks for you quik reply, but if the console doesnt open what has to be done?
(imported comment written by jgstew)
The console won’t open at all due to the timeout issue?
You could try manually deleting the console cache.
Does the console work anywhere in your environment? You should be able to use the console on the root server to deploy the fix to other machines with the issue. Otherwise I’d suggest using the REST api to set this setting. The other option would be to set the setting by hand in the registry on the console machine.
(imported comment written by hosmar)
thanks for you quick response, I have a Win 2k8 Server install on a workstation and the console run on the server itself. The console doesnt work from this server itself. I have tried deleting the cache too and doesnt work.
All I did was did an manual upgrade from 8.2 to 9.0
I just tried to access the URL directly and get this erro in the browser.
Server is starting
Status: Waiting for the client CA key to become available
(imported comment written by jgstew)
I would suggest opening a PMR with IBM, this sounds like it could be more than just a timeout issue.
You could try setting the _BESData_Comm_TimeoutSeconds setting in the registry.
(imported comment written by hosmar)
Thank you, unable to find the registry key though. I will raise a PMR and keep posted if the issue is fixed.
(imported comment written by jgstew)
The registry key path should be the following:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BigFix\EnterpriseClient\Settings\Client\_BESData_Comm_TimeoutSeconds]
REG_SZ values:
"value"="180"
"effective date"="Fri, 02 Aug 2013 12:00:00 -0400"
The “effective date” can be any date in the past, as long as it is properly formatted.
(imported comment written by hosmar)
The problem was the IP Address of the server was changed and this was creating the I realized when I executed the diagnostic tool. Changed the IP Address what the TEM Server was looking for and the console is working now.
Thanks a lot all for your time
(imported comment written by jgstew)
Glad to hear you got it resolved. Thanks for posting the follow up of how it was resolved, it is very useful.
Hi,
Im sorry, I dont understand the process that you did to resolve this issue.
Thanks all