Already posted this a while back but the thread was really two problems in one at that time so confusing.
We are upgrading a large number of v4.2.15 clients to v5.2.2. It's going pretty well, with the exception of a few Emergency Boot's required here and there and one unfortunate user who lost battery power on a laptop at the exact moment upgrade was being delivered and was left in a wierd limbo of v4 and v5 when it came to trying SafeTech recovery. But I digress...
A number of machines don't upgrade properly. That is to say they download all the v5 client files successfully (SCMLOG confirms this) and then after reboot, sbclientmanager.exe won't run. On investigation, it is found to be because SBDBMGR is still v4.2.15.
Now we've put in place the AV exclusions recommended by the Mcafee EKB but we still see the problem. And it always seems to be this particular DLL.
I'm not really sure what I can test / check / monitor during an upgrade to diagnose this one. Any suggestions welcome.
We don't have System Restore switched on for these machines by the way.
Not that I'm aware of. I did a Windows Search for any file containing the string "sbdbmgr" just in case it had popped up in the logs of something I hadn't checked. But no results returned, other than where I'd expect to find it.
How many users are assigned to systems experiencing this problem? Did you notice anything unusual in SafeBoot/EEPC client communication logs?
Timestamps on events maybe?
We've applied the v5 upgrade to around about 5,000 machines so far with 4 reports of this issue. There may be more but the users would not always be aware as the issue leaves them on a v4 login screen (although the warning text is from our v5 configuration so it's an 'in between' login screen). We are going to do a report on the machines and remotely check the DLL version on all to see the extent of the issue.
The 5,000 machines are upgraded by being moved into new containers and then having the new config of the container applied through group reset. The 5,000 are split into identical copntainers.
The SCMLOG.txt at upgrade appears ok, all files downloaded including SBDBMGR.DLL. Of course the SBCLIENTLOG is empty until we replace the DLL for the v5 version and reboot.
And there is 1 user to a machine by the way. I guess you were wondering if we have hundreds of users against each machine and the DLL update failed because the upgrade was taking so long to complete the "Import User" steps of the upgrade to v5?
No, no Host Intrusion Protection System or Data Loss Prevention that I'm aware of.
Just did some reporting on machines which appear to be running v5 sbtraymanager but still have a v4 sbdbmgr.dll, looks like we have a 17% faliure at the moment which is significant. Will probably have to raise a support case as this is a big problem. Why on earth would this DLL appear to be downloaded on upgrade but still be an old version that ends up in Program Files?
By any chance did client application directory changed between versions?
Does SafeBoot configuration manager run under different context than "local system" default?
Any errors in Windows Event log?
No, no directory change. Still Crogram Files\SafeBoot
So, during a 'good' upgrade... It appears that v4 downloads all the v5 files and shuts down SB Configuration Manager. At this point, sbdbmgr is still v 4.2.15 in Program Files. The user will then reboot at their leisure. On this reboot, the SB login screen still has a v4 appearance but has the text from our v5 container configuration. Then, v5 SB Tray Manager (running in task manager under the users profile account) and SB Client Manager (Running under task manager by SYSTEM) both run. On running, SB Client Manager records in it's log that it 'Updated' a number of files, including sbdbmgr.dll.
So my question is, what exactly is v5 doing when it 'Updates' the newly downloaded files? Maybe this is key to understanding where the upgrade is failing? Having said that, on our BAD upgrades, v5 never runs as the DLL is old. So presumably that first reboot after the 'new' SBDBMGR.DLL is downloaded, is the key to that file being updated in Program Files?