Good morning.. Question here: Recently migrated to new UMS server. Devices still registering to old, found in system reg where UMS is getting defined/enforced… How can I mass-update this for all devices? Wouldn’t this have to be a profile push? I’ve not had any luck determining source assignment.. Thanks!
Good afternoon Geoff, before pushing that setting I would check if there is a DHCP / DNS: kb.igel.com/endpointmgmt-6.04/en/with-the-same-external-database-26034910.html kb.igel.com/endpointmgmt-6.04/en/with-the-same-external-database-26034910.html
If that setting is changed already, then you might create a profile with the setting you have in your screenshot and push it globally.
Thanks @member. I should have mentioned initially, but I checked for the igelrmserver A record and a 224 scope option prior to discovering where the reg setting was applied and neither were defined. I since created the A record and new 224 scope option (for that scope) and manually removed the UMS cert (via other commands) for the device before rebooting to see if it would pick up changes, but it did not.
On a concerned device, could you start the UMS Registration Tool and try to register? Just want to avoid Port / Firewall misconfigurations:
I’ll get back to you on this tomorrow, Sebastien. Thanks!
@member Check it out, no issue. Customer also informed me today after plugging a UDP into the network, the device registered itself right up to new UMS automatically so sounds like I have everything in place correctly.. Challenge I’m facing now is really just getting registration updated automatically on existing devices still registered to previous UMS server. Thoughts?
Can you try to remove the old certificate on one testdevice and retry?
In a local Terminal or SSH: rm /wfs/server.crt
or
kb.igel.com/endpointmgmt-6.04/en/removing-a-certificate-26035715.html kb.igel.com/endpointmgmt-6.04/en/removing-a-certificate-26035715.html
@member So it seems that I can successfully remove the cert via other commands, then losing management control from new UMS (for obvious reasons), but shadowing into the device and rebooting thereafter doesn’t seem to result in the new cert/UMS getting picked up as expected. So as such now, result is there’s no longer a server.crt on the box. I’ve enabled terminal on another device and checked, able to locate and remove the server.crt file. Rebooted and results are the same, still ‘connected/registered’ to former UMS server (no crt)
what answer (IP) gives
ping igelrmserver
on one of the concerned devices?
Pinging correct IP of new server, old is .217, which I’m still seeing on the concerned device
Well, that makes maybe a difference. On a device where you removed the certicate and rebooted it: md5sum /wfs/server.crt and compare the output with devices registered on the old UMS and with of the new one.
Which UMS is there? Dumb question maybe when you migrated the UMS did you restored a tc.keytsore file somewhere in your procedure?
@member The server.crt is not getting regenerated on a device where I removed the cert and rebooted, so I cannot view the checksum to compare.
Although, I was able to do a comparison with the other device where I manually registered the other day and check this out, thumbprint is the same, and does not match that of my new UMS server. We did not restore the tc.keystore as part of this migration, as I would otherwise think the cert would match, is that correct?
Ok, but if the server.crt is NOT recreated: the device is registered somewhere.
So the simple existence of server.crt on the box is not a valid check for registration?
It is: server.crt existence means: registered. You wrote: “The server.crt is not getting regenerated on a device where I removed the cert and rebooted”
To further clarify that, as result, there is now NO server.crt on the device at all, since I first removed, rebooted, and it was not regenerated
Yes, and that means: the device is not registered. Is there an ICG Server somewhere? Because you sent in your last Screenshot a Fingerprint at the bottom…
There is no ICG at play for any devices at this client. That is the fingerprint of the tckey on the new UMS server, assumed it should be what is also reflected in the server.crt found on a registered device, no?
Is there a default pwd for rmclientcacerts so that I can view the keystore?
In that case I would go that route: openssl x509 -noout -fingerprint -sha256 -inform pem -in /wfs/server.crt and verifiy if the Fingerprint from the endpoint matches UMS 1 or 2
Bug in the code, perhaps?
And if you compare both fingerprints on Server side? are they the same?
So that’s the reason I was asking about a default password for viewing cacerts (assuming that’s the tc.keystore?) — Client previously tried to upgrade former UMS while users had it opened and the install has been corrupted ever since, unable to open UMS to verify cert fingerprint from the .217
There is no standard password from what I recall, but you could check it from filesystem: C:Program FilesIGELRemoteManagerrmtcserver there is the server.crt. But I guess it will match.
Oddly enough, the server.crt found in rmtcserver on both old and new UMS is the same, having the following thumbprint, but this does not match either of the fingerprints
Looks like tc.keystore is probably where I would need to take a closer look but I can’t crack it open with changeit
Let’s sum up:
• you had a UMS server that went broken and installed a new one
• you took a Backup (which DB are you using / where is the Backup from?) and restored it on a new server?
• you changed the igelrmserver alias to Point to the new server
• Apparently you also restored the tc.keystore (maybe from the backup)
• A device registered on the old server, should now register on the new server
So far, right? Please answer the ? just to be sure we are speaking the about same situation.
Is there any kind of issue you encounter from your NEW Server when sending a new Profile or moving devices between directories?
This all sounds correct as you’ve stated
Does the tc.keystore get picked up in a backup if all are selected? The backup we restored from was the one the client took before attempting the upgrade on the old UMS so I can’t account for its contents unfortunately but he said he checked all boxes.
So far (until I removed the cert), no- There’s not seemed to be any issue interacting/modifying device configs from new UMS
Ok, so the only issue is that “old” devices still have the “old UMS Server” in the RemoteManager List, right? If yes, you could try to create a profile where under System, Remote Management, UMS Server you put the new server in. Assign it to a few devices, reboot, and check the entry.
Ok.. Yeah, so that’s back to my original question then, if that’s the route I should be going with this since CNAME/scope option doesn’t seem to be working as expected for those “old” devices having former UMS registrations
Should have asked this questions before, but yes.
That is where I started this conversation, but thank you for your assistance!
Right, I wrote this suggestion in my second post (_If that setting is changed already, then you might create a profile with the setting you have in your screenshot and push it globally._) but I guess that was overseen 👍
I guess I just don’t understand where it is getting applied from still.. Because of that, it doesn’t seem to matter that I create a global profile and push out the new UMS
And it won’t let me delete that first one for .217 either, so what would that mean?
The device will first try the 217 and then the newer one. It will disappear after a few months, it‘s a more a cosmetic issue. If that bother you, I could script a command that changes that, in fact replaces it by the new one.
Gotcha.. Well as of right now .217 is still available for device registrations apparently (despite there being no igelrmserver service running) so how can we ‘turn it off’ and make unreachable in order to force it to roll over and register to secondary > .212 new UMS via profile
Not so much worried about the cosmetic, if we can eliminate the actual use of it otherwise but right now because it is evidently still functioning, it is technically more than cosmetic I guess
So if script to remove is the only way to eliminate it from the list and get it to stop taking priority in registration, i’m fine with that option as well
So also noticing now where the device I manually registered via the igelrmserver address the other day doesn’t seem to have the stale entry in its configs.. That’s interesting
I‘m not getting your point tbh… What is the 217 server doing? If no service is started and no Igel Processes are running on the server, the device will just catch the second one in the list after boot up: 212. So where is your issue?
Sorry, but I can‘t follow atm.
No worries, this is a bit of an odd and confusing circumstance to be in
Please try to reset a device to factory defaults, and describe what happens (or not) and what you would expect.
State of old (217) UMS server:
Up, online, serving as a print server. UMS is still installed and technically still ‘functioning’ apparently, since devices are still showing green checkmark registering to it. The attempted upgrade that corrupted the install however, has now made it where we’re no longer able to launch old UMS console, and the windows service isn’t showing anymore either, so it is effectively ‘functional’, but in ‘limbo’ the best that I can conclude at this time
And we need to be completely done with it, moved on and away from it, stripping out any reference but the devices continuing to hold onto registration to it is an outstanding problem.
Please check there if a Tomcat Process is running: if not: no chance that the device would ever interact with the server.
Please send a screenshot about the green Checkmark you are refering to in your last post.
And, please, don‘t forget my post here:
igelcommunity.slack.com/archives/C8FC01UNM/p1588181637385200?thread_ts=1587562357.274100&channel=C8FC01UNM&message_ts=1588181637.385200 igelcommunity.slack.com/archives/C8FC01UNM/p1588181637385200?thread_ts=1587562357.274100&channel=C8FC01UNM&message_ts=1588181637.385200
Second one in the list is a device that is maintaining registration to old UMS server, as indicated by the green checkmark.
That isn‘t saying that, it just says: the first server in my list is reachable via ICMP (he only shows the first one, not the second one 212 unfortunately). So, now, what happens on a device reseted to factory defaults?
Trying it now
Would be good to have that info publically disclosed on a KB somewhere because I’ve gone on a goose chase thinking that was the indication there, rather than a simple ICMP………
Factory reset seems to clean it up 👍
Ok, that means that your structure is working! So, I will take that point as a KB addition!
Curious if having no stored cert could have played into that working… I would think issuing a factory reset would be cause for the cert to get removed anyway, right?
As always, thanks @member !
You are welcome @member ! That‘s right: the device should then be in a Factory state until the Autoregistration process takes the device over and register it with UMS.
Continue reading and comment on the thread ‘How to bulk update IGEL OS devices to point to new IGEL UMS server?’. 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!