Figured this warranted it’s own post since it seems to be different form the other issues and failures being reported.
We tested the 9.5.12 update and are glad to report that the multiple reboot issue is no longer plaguing us. We’ve successfully updated several computers without issue on the 9.5.12 client.
The problem we’re having is that on about 50% of our computers after they come back up from the in-place upgrade the client starts up and gets an invalid sequence number response from registration.
Response: Invalid Sequence Number
RegisterOnce: Server requests invalidation of my computer id.
This happens regardless of the version of client installed. Since the action history is tied to the previous id we have no way of tracking the status of the upgrade other than checking the OS version and we lose action history.
That’s been my experience as well. I’m not sure whether there is any good option.
This isn’t authoritative, but it looks to me like during Windows Setup, when we’rw in a temoprary Windows environment, the BESClient starts up and sends in reports. The Setup process then restores the original registry HKLM\Software hive into the “new” Windows installation - including an old BESClient report sequence number (which is lower than the sequence numbers the active service is now sending).
Then, when it reboots into the “New” windows installation, the BESClient reads that restored registry key and sends duplicate report numbers incrementing from that old, restored sequence. Since the reports have duplicated numbers the server tells the client to reset itself.
It might be possible to prevent the client from sending reports during the Windows Setup process, but if something went wrong and Windows Setup hung or was left prompting from some user input, and the BESClient isn’t running, the system might be left unmanageable. Or you might have trouble re-enabling BESClient after Setup completes.
I’m not sure how I’d try to work around that, so I ended up accepting it in my environment and tried to skip every other Feature Update so we did them less frequently.
So this might apples/oranges && not apples/apples, but my env is running 9.5.10 & 9.5.12 on endpoints. I’m about 2300 workstations deep on a W10 IPU migrate from W7 w/ many more to go.
I ended up having to switch up my whole procedure, because I was seeing so many random issues trying to use the built in content. Here’s how my process runs:
I used the built in fixlets to stage a system and retrieve the initial c:\ipu dir.
I took that dir, modified the upgrade attended & upgrade silent bat files, and also the setupcomplete.cmd files. I did various things here that are environmental specific, but can provide further details on bat file contents.
once I had that how I wanted it, I bundled it all up w/ bfarchive.
I use a staging action to roll the payload out to clients and unarchive with bfarchive to the correct c:\ipu structure.
I have a registry and filesystem check to verify the systems are staged properly at which time they move into an IPU automatic group
I run upgrades against that group w/ a custom baseline that strips them of various drivers, incompatible progs, etc.
bounce
run a standard in place upgrade action from the OSD actions
Hi,
you say that with 9.5.12 upgrade the issue of the multiple reboot is solved. Could you please specify when it occurred and if finally the in-place upgrade was successful (apart from the multiple reboot) or not?
Which is the different behavior after upgrading to 9.5.12?
Did the issue of the invalid sequence number start to occur after upgrading to 9.5.12 also on previous client versions? Or did it occur also before?
Does it occur on previous client versions that are connected relays upgraded to 9.5.12?
Thanks.
The reboot issue addressed by 9.5.12 is fairly well discussed in BigFix 9.5 Patch 12 is now available. The fix included in 9.5.12 did address that issue for us.
As previously mentioned the issue of invalid sequence number occurs regardless of the client version. @JasonWalker’s description above fits with our observations.
We haven’t upgraded our relays yet and have no reason to believe they are involved in the issue.