Due to the red tape involved in changing a software package delivered to the machines in our organisation, we've been delivering SafeBoot 4.2.11 and then upgrading it to 4.2.15 from the server. This is working well, but with a v5 upgrade in progress it'd be a lot cleaner to start from 4.2.15, as well as reduce payload on the server in updating files on all our clients a day or two after initial install of 4.2.11.
Having just created an EXE from our default group, with settings configured for 4.2.15 client files, and handed it over to our packaging team for delivery testing, I notice that on install I get the line "Updating Local SSO data for user 00003ba4 with database changes". I don't recall this in our v4.2.11 installs and am wondering if I have a mismatch in the config on my default container and the Install set I created?
What exactly does this line mean? Is it only related to the user config? In which case, it's not likely to be any Machine Group setting right?
For info, we actally pre-create machine and user accounts prior to install, using a developed scripting tool interface here. If the machine account already exists (from a previous install) it is deleted and then created new prior to install. If a user account already exists it is reset, or created if it does not.
Well, the ID is just the user account. I'm just wondering why, on new install, it's updating local SSO data for the user object. Is this a feature of 4.2.15? As our 4.2.11 installs only do this:
07/27/10 10:32:39 installing boot protection
07/27/10 10:32:52 machine name = "XXXXXXXX"
07/27/10 10:33:06 creating new database entry
07/27/10 10:33:06 group ID = 00000063
07/27/10 10:33:16 machine ID = 0002ea0a
07/27/10 10:33:22 setting our address to "10.215.189.93"
07/27/10 10:33:23 checking for user updates
07/27/10 10:33:24 adding user: ID = 00003350, name = "YYYYY"
07/27/10 10:34:14 checking for Windows logon updates
07/27/10 10:34:14 checking for screen saver updates
07/27/10 10:34:14 checking for user updates
07/27/10 10:34:21 checking for file updates
07/27/10 10:34:53 checking for hash updates
07/27/10 10:34:53 transferring audit information
07/27/10 10:34:53 performing encryption/decryption
07/27/10 10:34:53 encrypting C: (disk = 0, partition = 0)
But the v4.2.15 is doing:
installing boot protection
09/22/10 08:48:17 machine name = "XXXXXXXXX"
09/22/10 08:48:17 machine already in database
09/22/10 08:48:18 machine ID = 000309ac
09/22/10 08:48:25 setting our address to "10.237.50.108"
09/22/10 08:48:25 checking for user updates
09/22/10 08:48:26 adding user: ID = 00003ba4, name = "YYYYYYY"
09/22/10 08:48:27 updating local SSO data for user 00003ba4 with database changes
09/22/10 08:48:50 checking for Windows logon updates
09/22/10 08:48:50 checking for screen saver updates
09/22/10 08:48:50 checking for user updates
09/22/10 08:48:53 checking for file updates
09/22/10 08:48:58 checking for hash updates
09/22/10 08:48:59 transferring audit information
09/22/10 08:48:59 performing encryption/decryption
09/22/10 08:49:00 encrypting C: (disk = 0, partition = 0)
Is it purely because we are pre-creating the object first, in the 2nd example? Or do you think it means there is a config difference between the Install Set and the Database container for with the machine or user object? I just don't understand why it's updating SSO data? Especially as we don't enable any of the Logon options in our machine config and there are no SSO related settings within a User Object?
Cool. I don't see it as a problem, I just want our synchs to be as slick and efficient as possible so I found it very curious.