IÕm hoping someone can help me with this confusing issue. I am in the middle of an SA to MAG migration. My users have been given Pulse and those who are not on domain-joined machines go to an external website to get a page with bookmarks Ð website.company.com.
Last weekend, I cutover the external A record for website.company.com to look at MAG device instead Ð website.company.com = external IP of MAG device. Everything broke!
- Some Pulse users were connecting but not being given an IP so they couldn't get to anything on the network
- Some Pulse users were getting website.company.com as a new connection set, even though they were pre-configured with websitenew.company.com
Nobody has been able to use Pulse since, though in my testing I noticed that if I reinstall Pulse everything starts working again. Does anyone know why a simple A record change would break everything? JTAC are also looking but equally mystified. Obviously I canÕt chance another cutover until this is resolved so any advice you can provide would be appreciated.
What is the case number? How was Pulse deployed in new environment? It sounds like there may be a deployment issue as the preconfigured connection is set on the Pulse client, then given overwritten with the old connection. In regards to the IP address issue, we would need to take a look at the logs to see if the device is having issues assigning IP address or if this is a client issue itself.
Thanks for the response. Case number is 2014-0831-0222: Pulse cannot connect. Pulse pushed out initially via SCCM and my version was manually installed. The cfg file had only websitenew.company.com so not sure why it would change itself, on 2% of machines, to website.company.com.
Re server-side, the logs are showing no issues and is giving out the IP. The client is not receiving the IP.
To make matters more confusing, it was reported last night that some people are now able to use Pulse again (100 out of 8,000).
Thank you for the case number. I've reviewed the data with the case owner and confirmed host checker is failing when using Pulse, but it does not seem to be the case for NC. Since Pulse has HC built-in, this could be the reason for the different behavior.
We will need to enable further debug logging for HC to determine what rule is failing.
Hi Kita, Zanyterp,
The server side version is 7.4R11.
What's the server-side version? There is an issue with 8.0 that host checker may pause and connections for pulse (only) will fail
Under what circumstances does this occur?