File Group Removal

[jvolltrauer]

We are currently using EEPC 5.1.7 and are also using autodomain script for installations. The problem we were having was upgrading from 5.1.3 to 5.1.7 was failing. The fix was to uncheck the file groups that involved the autodomain scripts.

Now that is generally resolved, but we are still seeing errors the following.

3/19/2009 10:31:08 AM Transferring local audit information to database
3/19/2009 10:31:08 AM Checking for file updates
3/19/2009 10:31:20 AM Updating file "SBClientStatus.lng"
3/19/2009 10:31:20 AM Updating file "SBUILib.LNG"
3/19/2009 10:31:21 AM Updating file "SBClientHelper.LNG"
3/19/2009 10:31:21 AM Updating file "SBCredProv.LNG"
3/19/2009 10:31:22 AM Removing file "C:\Program Files\SafeBoot\SBAdmCom.dll"
3/19/2009 10:31:22 AM Error [e0130006]: Error opening file
3/19/2009 10:31:22 AM Applying configuration
3/19/2009 10:31:22 AM Synchronization complete

I can delete the SBAdmCom.dll file manually and replace it but the error is still there. I don't think I have the understanding of how the file update/installation system works. I have removed the entry in SBFILES41.LST and the error does go away, but I'm not sure this is a fix for 500 users.

I have tried support and received they politely said we can't help you as it's not supported.

[SafeBoot]

the root problem is you have two file groups with exactly the same files assigned to the machine - so each group updates the other's files in a loop.

You need to work out why you've got this situation and remove the group that you don't want to keep.

[jvolltrauer]

I thought that as well, so I did a search in the sbadmin dir for any text file that had an entry for sbadmcom.dll and only found the ini that was added for the custom file group. It is called iset_ad_scriptfiles.ini. Am i correct in assuming that most file groups will have an ini with a list of files in it?

I just did a search in the file groups and that's the only location I can it being.

Thanks for the help.

[SafeBoot]

it could have been added manually.

you'll need to check each selected file group in SBadmin.

[jickfoo]

would love to know if there was a final resolution to this as we have a test user getting the same error.

[SafeBoot]

it's usually that you have tried to deploy the same file from two file groups at the same time...

[jvolltrauer]

My work around was to create a new file group with just that file in it.  Simply adding it and then later removing it solved the issue.

[TechSecurityNat]

We had the exact same error for SBAdmCom.dll and it had nothing to do with multiple file groups.  We were upgrading AutoDomain.  This file is installed by the AutoDomain ISET.ini with file type parameters that make it a "Self-Registering Dll".  It will not remove the file if you uncheck the file group.  To compound the issue, when it fails to remove this file, it stops processing all other file update related tasks.

Then we tried rechecking the file group to just leave it for now and at least get rid of the error message, so the clients wouldn't see an error and flip out.  No go.  It received instruction to remove the file, has not yet done so, and will continue to attempt removal for the end of time.  Manual removal of the file did not stop the error message.

RESOLUTION

In your file group for AutoDomain, right click SBAdmCom.dll and choose properties.  Click the Advanced button on the left.  In the File Type drop-down, change it to "Windows DLL".

It will now successfully sync and remove the file.

The resolution mentioned above, with manually adding the file to a group, also results in the file being labeled as a Windows DLL, which is why it works.

When importing a new version of AutoDomain, alter the ISET.ini to comment out the line containing "Type=00400044" and it will import the file as a Windows DLL.

I commented on this in another message, but it was "off-topic" and was never addressed.  If anyone can give a better solution, or reason why that file is initially set as self registering, please do so.  I've had no issue with the function of AutoDomain with this configuration.

on 12/10/10 8:24:43 AM CST

[SafeBoot]

it's self-registering because it's a com object and needs to be registered 🙂

If you don't set it like this, then the script has to try and register the API itself, which may or may not work depending on what access rights the script gets run under.

[TechSecurityNat]

Here's exactly what I see, both in production and dev environments...

First I uncheck the AutoDomain File group from my machine and sync.  You can see it removes fine, because I have SBAdmCom.DLL set as a Windows DLL.

see remove pic

I then alter SBAdmCom.DLL to be a Self Registering DLL.  Then I check the file group and sync my machine, getting errors.

see add pic

Then upon all future sync activities, I get the same error.  Please note that in the future, adding ANY new file groups is messed up because it stops after this error.

see recurring

I will note that building an install set with the file set as Self Registering DLL works just fine to install and regardless the setting, it appears to run fine for us.

In the final screenshot, I believe the Client Status operation is being shown to run under the SYSTEM user, so permissions aren't an issue.  With this setup, how are we to ever upgrade AutoDomain?

Message was edited by: TechSecurityNate on 12/10/10 2:36:54 PM CST