1 2 Previous Next 14 Replies Latest reply on May 11, 2010 8:39 AM by peter_eepc

    SB Clients Removing their Own Files!

      Wierd one this, and a bit alarming.

       

      Just upgraded our v4.2.15 environment to v5.2.2 and everything seems ok except when our admins change the user account on an existing install. The new user account is added, the old one is removed and then SB starts removing files before shutting down the config manager. This then leads to big problems on the machine after reboot.

       

      Any ideas?

       

      03/23/10 15:19:22 database = SafeBoot Server A
      03/23/10 15:19:22 address = safebootxxxxxx
      03/23/10 15:19:22 server port = 5558
      03/23/10 15:19:22 authenticate = Yes
      03/23/10 15:19:22 checking for machine configuration updates
      03/23/10 15:19:23 updating machine configuration
      03/23/10 15:19:24 setting our address to "X.X.X.X"
      03/23/10 15:19:24 checking for Windows logon updates
      03/23/10 15:19:24 checking for screen saver updates
      03/23/10 15:19:24 checking for user updates
      03/23/10 15:19:25 adding user: ID = 00016f38, name = "603485464"
      03/23/10 15:19:26 removing user: ID = 0000892a, name = "602289667"
      03/23/10 15:19:26 checking for file updates
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\sbclient.chm"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\viewhlp.chm"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\sbpreins.dll"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\sbgina.ini"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\SBM.INI"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\safeboot.cod"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\sbfeatur.ini"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\safeboot.bmp"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\world.avi"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\sberrors.ini"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\sbhelp.ini"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\02000021.gbl"
      03/23/10 15:19:27 Removing file "C:\Program Files\SafeBoot\02000701.gbl"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\02000801.gbl"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\02000401.gbl"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\02000402.gbl"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\02000901.gbl"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\02000902.gbl"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\02000903.gbl"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\BT_logo.bmp"
      03/23/10 15:19:28 Removing file "C:\WINDOWS\system32\drivers\sbflop.sys"
      03/23/10 15:19:28 Removing file "C:\WINDOWS\system32\drivers\sbalg.sys"
      03/23/10 15:19:28 Removing file "C:\WINDOWS\system32\drivers\rsvlock.sys"
      03/23/10 15:19:28 Removing file "C:\WINDOWS\system32\drivers\sbprcctl.sys"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbgina.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\psapi.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbm.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbalg.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbutils.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbipc.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\scom.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbfiledb.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbxferdb.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbdbmgr.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbgroup.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbfile.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbmchn.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbuser.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbhashes.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbcfgmgr.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbhook.dll"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\SBKBESB42.DLL"
      03/23/10 15:19:28 Removing file "C:\WINDOWS\system32\drivers\safeboot.sys"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\safeboot.sys"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbmgrnt.exe"
      03/23/10 15:19:28 Removing file "C:\WINDOWS\safeboot.scr"
      03/23/10 15:19:28 Removing file "C:\Program Files\SafeBoot\sbrunnt.srg"
      03/23/10 15:19:29 Removing file "C:\Program Files\SafeBoot\ntdrvs.srg"
      03/23/10 15:19:29 Removing file "C:\Program Files\SafeBoot\XPSP2.srg"
      03/23/10 15:19:29 Removing file "C:\Program Files\SafeBoot\sbinshlp.dll"
      03/23/10 15:19:30 Shutting down SafeBoot Configuration Manager

        • 1. Re: SB Clients Removing their Own Files!

          It's worth noting that in our client files list. We have client files for 4.2 and client files for 4.2.15

           

          In the files properties of our machines we only see the client files for 4.2 listed (not ticked). The 4.2.15 client files are not displayed as an option to tick.

          • 2. Re: SB Clients Removing their Own Files!

            it will remove files if the file group they are part of is removed from the machine. So, I guess that is what you are doing?

             

            If you have a file group you can't select, it probably has the wrong properties (ie, it's not a client type file group).

             

            So, I guess somewhere you are making a policy change to remove the files, but not adding other ones back in?

            • 3. Re: SB Clients Removing their Own Files!

              Yes. Just before your post, I noticed that the most recent client files that we were using, prior to upgrade to v5, were not marked as Client Files in their properties. This appears to be why the files were not avaliable in the Machine Object properties. Upon marking them as client files, they appear in the machine object properties and the tick is in there already.

               

              I am wondering if, when we updated an object by changing the user account, it then did a check for File Updates, saw no client files ticked and began to remove them.

               

              If this theory is correct. I don't understand why all machines have not had this issue on synch, as synch does a "Checking for file updates". It only seems so far to have affected machines where we changed a user account?

              • 4. Re: SB Clients Removing their Own Files!

                maybe you did "reset to group configuration" ?

                 

                The client checks for file updates on every sync, unless you disabled that option.

                • 5. Re: SB Clients Removing their Own Files!

                  The synchs do check for file updates. As far as I can tell, all synchs from regular users are unaffected. However, when changing the user account on a machine, (and I've tested doing this both with "Update Machine Configuration" and then not) the File Update seems to kick off a removal of client files, which is doesn't really complete before shutting down the SB Config Manager, leaving a broken install.

                   

                  Had the regular synchs removed SB client files, I think I'd have had catastrophic client issues by now. Seems strange that a regular synch would leave the client files as they were after "checking for file updates" but would then revise the Client Files when a user account was changed and the machine was synched.

                  • 6. Re: SB Clients Removing their Own Files!

                    the log you posted is removing v4 files, so what is v5 in your environment?

                     

                    you know you can't have both v4 and v5 files selected at once? That will never work.

                    • 7. Re: SB Clients Removing their Own Files!

                      I can't see any relationship between user sync and file sync - the two are completely unrelated. I think there must be something else going on. Files get changed based on revision checks between sbfiles..lst and the file groups associated with the machine in EEM - thats what sparks off an update or removal.

                      • 8. Re: SB Clients Removing their Own Files!

                        EEM is now v5. All clients remain on v4.2.15 at present until we begin a phased upgrade.

                         

                        As far as I can tell, since the upgrade, regular synchs (which include the line "Checking for File Updates") are not causing the clients to remove files (thank god!)

                         

                        BUT....changing a user account on a machine and then synching that machine results in SB Client files removing at the "Checking for File Updates" point in the client synch.

                         

                        My thoughts are that this could be because None of the machine groups had any client files ticked after upgrade! Mainly because the Client File Set in the Server Tab on EEM was not set to "Client Files".

                         

                        I am still waiting for some test machines to unencrypt so I can test, but if I'm correct in my idea that it was because no client files were marked against the machine groups after upgrade then one would assume that all machines would have removed client files on a normal client synch in the morning?

                        • 9. Re: SB Clients Removing their Own Files!

                          I forgot to follow up this thread.

                           

                          I think I found something that was potentially disastrous but is now fortunately resolved.

                           

                          In our v4 infrastructure it seems we had two v4 file groups, v4.2.11 and v4.2.15.In the past we had upgraded from 4.2.11 to 4.2.15 and imported the file groups for the later version into a client files set.

                           

                          Now here's the interesting thing... I can't roll back to confirm but it would appear that only the 4.2.11 Client files were actually marked as "Client Files" in their properties. Despite the 4.2.15 files not being marked as Client Files, they still appeared as an avaliable file set in the properties of all our machines.

                           

                          So....when we upgraded to v5, v5 appears to have been more sensitive to the fact that the 4.2.15 file set was not marked specifically as "Client Files". Consequently, the option to have these client files was removed from the properties of all our machines. Any machine objects which had 4.2.15 client files attached then found that if any changes were applied to the object, the client files removed themselves!

                           

                          The fix was obviously to go into the file groups and mark the 4.2.15 client files as "Client Files" which then made them reappear (already ticked for those that had been running 4.2.15) against all of our machines.

                           

                          So, if you've still followed me here, I would recommend VERY strongly that any Admin upgrading from v4 to v5 should make certain that their v4 file sets are marked in their properties as "Client Files"! Otherwise there is the potential here for all machines that have any config changes applied to suddenly dump all their client files and break install I actually think this is important enough that it should be put in any future v4 to v5 upgrade or migration docs / guides.

                          1 2 Previous Next