Hello iGel Slack community! I’m looking for anyone who may have experienced inconsistent profile application on their iGel devices. We have recently employed a new policy (enabling Phlips Speechmike channel) that doesn’t always take effect on the target endpoints, and we’re trying to understand why.
Hello,
I experienced that but it always happened because of different Firmware states on endpoint side, network communication issues or session related profiles where the session overwrite checkbox was checked. That‘s something that should be solved quickly by opening a Igel support Ticket, did you contact them already?
Did you checked the local configuration after applying the change, by opening the cobfiguartion on Igel setup or in UMS by context menu / edit configuration?
Can you provide the profile and sone infos like concerned firmware / UMS?
Thanks for the reply! I do have a ticket open, but haven’t heard back from them yet. Looking to understand the policy application process a little better. Our biggest concern was UMS saying a policy is applied, when functionally it clearly has not.
We have few in the mix. 5.11.100.01 for some older thin clients (and UDC converted workstations) and 10.03.210.01 for our newer devices. UMS versions 5.07.110
*version
We can check the thin client config through UMS, and pull the config (xml), which both show the Philips speech channel enabled…but the microphone doesn’t work properly. We found today that most devices were succeeding in taking the policy when we choose “update now” instead of “after reboot”. That didn’t make any sense to our team, so we’re looking for clarification.
That sounds like a network issue (I know, it sounds weird)… Can you please check and double check 😅 that the ports TCP/UDP 30001 are opened from endpoint to UMS Server? Create a profile: Accessories=>Terminal=>Add a session with the blue star, assign the profile. Start the terminal on endpoint side, login as root, and send one of the following commands:
probeport IPOFYOURUMSSERVER 30001
nc IPOFYOURUMSSERVER 30001
if it fails, there is a port Firewall issue.
Why? Pushing a config goes UMS=>Endpoint on 30005, pulling it on reboot from Endpoint=>UMS on 30001
my apologies for abandoning this question, i very much appreciate the information. i’ll give this a shot asap.
If it process of pulling policies is interrupted (e.g. 802.1x profiling can interrupt network connectivity), will it attempt to retry? How intelligent is that interaction?
*If the process
Yes, at least after the next reboot or sending. If you want to test it: open a terminal and issue the command: get_rmsettings
Continue reading and comment on the thread ‘Issues with IGEL UMS profiles not alwayds being deployed to devices’. Not a member? Join Here!
Learn more, search the IGEL Knowledge Base
Ask a question or comment on the above message thread?
Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.Submit a question, or Join Today!