How are you deploying the update? Policy, Mdm Commend, etc?

Are your end users Standard Accounts or Administrators?

- Local or Mobile?

Are you using a 3rd party tool to login? Jamf Connect / NoMAD?

(It sounds like you are using Native macOS Login Window but i just want to be sure)

Update is being deployed using a script with a policy that calls the startosinstall command to kick it off. But a couple of the impacted Macs were upgraded from Big Sur via Sys Prefs > Software Update before enrolling in Jamf.

We have a mix of standard and admin user accounts.

Our Macs are still AD bound mobile accounts. We will be moving to local accounts later this year (hopefully).

Still using the native macOS login. We do have NoMAD on all our Macs but just for AD password sync and issuing Kerberos tickets.

We also have a fun mix of security agents installed on all our Macs; Pulse Secure, CarbonBlack App Protect, CarbonBlack Cloud Sensor, Forcepoint DLP, Jamf Protect, Zscaler, and Cisco AnyConnect (VPN). However, while I have been testing with a Mac that's in this "broken" state I uninstalled most, and it doesn't appear they are to blame.

Well **bleep**! Okay, a lot of moving parts here. Best I can recommend (which you've already been doing) - is troubleshooting 1 by 1. Enroll a mac, bound with nomad & upgrade, see if the problem exists & then start over adding 1 at a time your security agents.

Upgrading from Big Sur alone is also crazy to see. I could understand an older version.

If you haven't done so already, review your Filevault encryption policy / config /etc & verify its setup up correctly.

I have a feeling this is because the accounts are mobile accounts sync'd with NoMAD but thats just a hunch.

I mean, if it truly is FileVault could potentially regenerating a key fix it?

sudo fdesetup changerecovery -personal

Hi,

Did you get anywhere with this? I'm seeing it as well. 

Freshly flattened macbook with Monterey on, mobile users (non admin). If the macbook is on the network via ethernet they can log in OK but if it's off the network so logging in with cached credentials then the the login stalls with the progress bar at about 50%.

Since unlock/login is now unified I'm not sure whether it's doing the unlock but the failing the login or quite what's going on. Also just seen the missing menu bar and half broken keyboard thing when I did get it logged in on the network.

Ian

Having the exact same problem at De Montfort Uni, has anyone found a solution yet? 

@ianatkinson @tech90210  

Still no solution, Apple had me send them SysDiagnose logs from both the stalled login and from when I get in where the menu bar is missing. The also had me run an lsappinfo when I was able to get in where the menu bar was missing (which wasn't easy) and its showing "Installer Progress" as the topmost process running.

From what I can tell while troubleshooting is that it appears to be failing during the unlock. I only assume that because disabling FV clears up the issue completely. I can provide users their FV recovery key and they can get into their Mac at the next login window.

What model Macs is this happening on for you? What 3rd party clients do you have installed? (ex. NoMad, Jamf Protect, etc..)

We ONLY see this on late-2016 and mid-2017 MacBook Pros but I am curious if its happening on other models.

I am so ready for this issue to go away...we have around 500 Macs in our environment and have stalled our Monterey upgrade until this can be addressed. The only Macs we have going out right now with Monterey are new M1 Pros that ship with the OS. 

I've done some more testing on this today.

We're only just looking at Monterey so I don't have a big install base to work with but we've replicated it on 3 MacBook pros which are all model  '15-inch Retina MacBook Pro (Mid 2015)' so that's at least 3 models it affects. Maybe it's any T2 Intel?

I was mistaken in that the one I saw the other day was a flatten it was actually an upgrade from Big Sur to Monterey (done via JAMF so a download of the full installer to /tmp not via app store or software update).

I have fully flattened one of them though and can replicate the same issue so I would say it's nothing to do with the machine having been upgraded.

The no menu bar/broken keyboard thing seems to happen if you power off during the stuck unlocking screen, plug the network cable back in, power back on and then log in as if it breaks the subsequent successful login. After a second reboot it's then back to normal, bizarre....

My conclusion on this is it's a Monterey bug with Filevault + mobile accounts when the domain isn't visible, works fine with the network cable in or with a local account. This is on 12.3 so a current bug.

I've tried this again today with the newest Intel one I can find which is 'MacBook Pro (16-inch, 2019)', although it takes a while it does log in OK in the scenario on this one so it may be model specific.

The progress bar sticks about half way like it did with the others, I timed this at ~22 seconds until it got stuck and ~1'22 until it logged in so I'd go so far as to suggest there's a 1 minute timeout in there somwhere when it's off the network that doesn't work properly on some older models?

Ian

What is your process to reproduce this issue? I have trouble sometimes reproducing this but I found doing a password reset usually triggers that but its not all the time.

This morning I found that if you also hard power off while logged in I can reproduce the no menu bar issue but if I shutdown or reboot by choosing the option in the Apple menu the issue doesn't appear and its back to normal. This is definitely a bizarre issue...it also makes no sense how this just pops up randomly on some of our users weeks after upgrading to Monterey.

I really wish my org could just replace the 160 or so 2017 and older MacBook Pros we have so I could walk away from this one since it does seem to be model specific. But MacBooks aren't cheap so.....😆

Apple emailed me this in regards to my ticket so it sounds like their engineers are stumped by this just like the rest of us are who encounter the issue...

Apple is making progress in the investigation, narrowing down the circumstances under which the issue may occur. It appears as though when the installer is running in the background while other applications (processes) are functioning in the foreground, the installer needs to regain control and is unable to continue. We are attempting to determine exactly what circumstances are needed to cause this, as this is a rarely reported occurrence across all our customers.

The test process that I've used for this is

• flatten machine (either to Monterey or Big Sur then upgrade to Monterey, doesn't seem to make any difference), as part of this our AD bind happens and will be set to mobile accounts
• log in as admin and perform the encryption/key escrow to get FileVault on
• with network cable inserted log in as an AD user, this will create the mobile account for that person
• reboot and check the AD user can unlock the disk and log in (they can)
• remove network cable
• reboot and check the AD user can unlock the disk and log in (they can't)

Looking at the list of MBP models over the last few years I think there must be 3 that are affected from the testing everyone has done then, essentially 2015-2017 models:

• OK - 2021 MacBook Pro (14-inch, 2021) ...
• OK - 2020 MacBook Pro (13-inch, M1, 2020) ...
• OK - 2019 MacBook Pro (16-inch, 2019) ...
• OK - 2018 MacBook Pro (15-inch, 2018) ...
• Affected - 2017 MacBook Pro (15-inch, 2017) ...
• Affected - 2016 MacBook Pro (15-inch, 2016) ...
• Affected - 2015 MacBook Pro (Retina, 15-inch, Mid 2015) ...
• Monteray not supported - 2014 MacBook Pro (Retina, 15-inch, Mid 2014)

I don't know about anything else like Macbook Airs etc. from the same period? We don't buy anything other than MBP here since they're all heavy Adobe users.

We currently have 55 M1s deployed with Monterey at the moment and its a mix of these 3 models. So far, none of them have experienced this issue.

2021 MacBook Pro (16-inch, M1 Pro 2021)

2021 MacBook Pro (16-inch, M1 Max 2021)

2020 MacBook Pro (13-inch, M1, 2020)

I've also seen this issue a few times - twice it happened on 15-inch Retina MacBook Pro with TouchID (Mid 2017). First time in Monterey 12.2 and again recently on 12.3.1. Suddenly computer won't wake from sleep properly(black screen), user will force it to shut down, after restart no menu bar and trackpad/keyboard don't work properly. Restarting computer again seem to resolve issue. Haven't seen this before Monterey. Computers joined to AD with mobile accounts, have NoMAD installed for Keychain syncing and Kerberos tickets renewal.

Its happening to our fleet of our 2021 MBPro M1 on Monterey.

When signing in using ethernet-- our mobile accounts take about 20 seconds but eventually login.

But if you unplug the ethernet, restart and try to login again (with the same mobile account), it will begin to login, and when the progress bar gets about 35%, it'll stall for 40 seconds, and then take me back to the login page.

When I try to log in again it works without issue, but its frustrating to have to type in your password twice (when you shouldn't have to). 

We also have FileVault turned on. Running MacOS 12.3

Interesting, that seems like a similar issue but the machine is handling it a little differently. On the older models you don't get returned to login when it's stuck it'll just sit there until you force power it off (in my experience anyway)

That is really interesting and definitely a similar issue but your users do eventually get logged into their Mac, ours can't get logged in unless we go through the one of the processes I mentioned in the original post.

I will pass this along to Apple that others are reporting similar issues with newer models that have the same config we are currently using. I want to demobilize a user having this issue and unbind their account to see if these issues go away. I can tell you the just unbinding from the domain didn't resolve anything in our testing.

Hello! Wanted to touch base with everyone on here to see if any of you have resolved this issue. Apple is telling me they can't find anything in their logs so they want me to do isolation testing to narrow it down to one of the agents causing the issue. I've tried removing all of them, with the exception of Zscaler for our proxy and AnyConnect for VPN, but the issue persists. The only thing I haven't been able to test is whether or not moving the user account from mobile to local resolves anything. Anyone else have anything new on this issue to share?

I couldn't get any further on with it, it's a bug Apple need to fix I think. In my testing environment there were no other odd bits of software installed like proxy/VPN stuff.

Update:

We finally had a chance to test demobilizing a user who has this issue. After moving from a mobile to a local account the issue is gone! At least so far after a couple reboots it looks like its resolved.

I really hope this is the case but after dealing with this strange issue I wouldn't be surprised if it came back in a few days or weeks. I sure hope this is the final answer though.

I now have this problem to with a 15" 2017 MacBook Pro. I tried this fix and apparently it works. 
But is there a more permanent solution yet or still no updates ? 
thx for your work btw

I fixed the Issue by running Onyx on the troubled Mac and the problems were gone.

Hi,

Did anyone who was dealing directly with Apple on this get to a sensible resolution as in it'll be fixed in an OS update? We're having to hold off installing Monteray for a lot of staff on laptops until this gets sorted out :(

Ian