UPDATE: February 12th, 2022. Earlier this week Apple released macOS Monterey 12.2, and just as was the case with macOS Monterey 12.1, I updated the same device in the same manner as before, with one difference. Instead of signing out of the mobile account, I used it to perform the update. After I did the upgrade, I was able to login right away without any issues. I have not experienced the "account being locked" issue yet. Time will tell on whether or not I will, but I suspect not. If you are still experiencing this issue on macOS Big Sur, I think the solution is to upgrade to macOS Monterey, so you no longer have to deal with the issue.

UPDATE: December 17th, 2021. Apple released macOS Monterey 12.1 a few days ago and I updated the same device that was experiencing this issue. Once again I was able to login again. However, I did experience the "account locked" issue again prior to upgrading after rebooting the device due to some issues with Wi-Fi. After waiting the hour, I was able to login again. I wonder if there was still something going on with macOS Monterey 12.0.1 that was causing the account lock out problem.

UPDATE: October 31st, 2021. I have just updated the same laptop that was experiencing this issue to macOS Monterey, version 12.0.1, and I was able to login to the Mobile Account immediately after upgrading without any issues. The initial login took a bit longer to actually show the desktop as compared to logging in to the local user account, but it did login. I did notice the screen below when upgrading to macOS Monterey. It popped up before installing (As a note, I upgraded using my local user account and not the mobile account that is on the MacBook Pro)

I do not recall this popup appearing when I upgrade to macOS Big Sur. It very well may have, but I might have not paid attention at the time, or I had logged out before doing the install, I honestly do not recall. I suspect that there was a major underlying system overhaul that was needed and it was too much of a problem to fix for macOS Big Sur, therefore it was pushed off to macOS Monterey, but that is merely a guess. I am not going to call this problem fixed until there is another update to macOS Monterey to be able to verify that the issue (outlined below) is indeed fixed.

The past year has seen a significant change in things throughout the world. It has been almost a year since the entire world was turned upside down with Covid-19. One of the biggest changes that has been made is that many more users are working from home. This has included many people, like myself, taking their work laptops home in order to be able to work.

Quite often laptops are connected to a directory service, like Microsoft's Active Directory, or LightWeight Directory Access Protocol, or LDAP. For many, when new devices are setup and configured, they are connected to Active Directory or LDAP. macOS can connect to an Active Directory domain. If you are physically in an office, then it is not a problem, it will always be connected. However, issues can arise when a device is connected remotely. I have run into an issue with my setup. It was originally configured while at the office, and it was connected to Active Directory. This has not been much of a problem, except for an issue that has only turned up since I have upgraded to macOS Big Sur. Before we get to the problem that I am experiencing, let me discuss the setup.

The Setup

As mentioned, my work laptop is connected to an Active Directory domain. I connect to work by using a Virtual Private Network, or VPN. Once I am connected I have full access as if I was in the office. The VPN setup we use requires its own software to use, and I cannot connect using the native macOS VPN connection.

When the MacBook Pro was setup, it was configured to use a Mobile Account. This means that the network credentials can be used to login and be able to use the cached credentials when connecting to resources without needing to enter in the same credentials time and again. This configuration also allows me to use Touch ID on the MacBook Pro.

Along with being configured for a mobile account and active director, there are also two local administrator accounts, as a precaution. One that I know the password to off the top of my head, and the other I would have to look up, but I can look up if absolutely necessary.

When working from home, I typically use my 27-inch iMac for most of my work and my MacBook Pro is used for work-specific applications, like chat, email, and video conferencing. I have all of my favorite development tools on my iMac, so I prefer to use that; along with the larger screen size.

I have a Mac mini that sits at the office, which does not have the same issue, probably because it is always connected to the Active Directory domain. I am typically connected to the Mac mini when I am working, by using Screen Sharing. Now that we have discussed the setup, let us get to actual problem.

The Problem

With each security update to macOS Big Sur I have run into an issue after upgrading. When the update finishes and the login screen shows, I attempt to log in to my account. But I get the following error: "This account has been locked. Please try again in 15 minutes". This is on the first login attempt after upgrading.

The first time I got this, with the upgrade to macOS Big Sur 11.1, I was baffled, but after 15 minutes I was able to login. I noticed it, but was not too concerned. I experienced the same thing again when upgrading to macOS Big Sur 11.2. Again, it indicated my account was locked out for 15 minutes.

I recently upgraded to 11.2.1, and again the same thing issue occurred, albeit with a slight twist, and it was much worse. Instead of being 15 minutes, it was 30 minutes. As was the case in the past, I waited the necessary amount of time and attempted to login. Unlike the prior instances, my account would not login. After trying a couple more times, it indicated that my account was locked for an hour. Again, I waited the hour, attempted to login, but could not. I was able to find a workaround.

The Workaround

Since I could not login with my mobile account, I logged into one of the local administrator accounts, to verify that I could still login, and I could. I then connected to the office using the VPN. This was so that I could verify that it was an issue specific to the MacBook Pro and not my active directory account. The fact that I could login means that it was not an issue with my Active Directory account and this verified that the issue was definitely restricted to my MacBook Pro.

Since I was able to login using the local admin account, I then tried connecting my MacBook Pro to a hotspot to be able to try and connect via the VPN to be able to access resources. Unfortunately, this did not work. The routing just was not setup properly, and since the hotspot I was using was my iPhone, it would be quite difficult to setup a proxy and have everything work as expected.

On a whim, I tried to connect from my iMac to the MacBook Pro, using Screen Sharing, while I was logged into my local admin account. However, instead of using my local admin credentials to connect, I tried to use the mobile account credentials. Shockingly, they worked. It should be noted, that the login window still indicated that my account was locked.

Now, if you have used Screen Sharing before, once you have validated your credentials, whether they are local or in my case a mobile account, you are given two options. You can either "Share the Display" or "Login as yourself". I opted to login as myself, in this case is the mobile account. Again, shockingly, this actually worked. I was logged in again to my Mobile Account, which is great. When I logged in, this disconnected the VPN connection on my local admin account.

At this point, I knew I was logged in, and that the account was working. I then logged into the MacBook Pro locally, and it was logged in. In order to verify that I would be able to login again, I closed the lid so that the laptop would sleep. I re-opened the lid, and guess what I saw. "This account is locked for 28 minutes". Again, I waited 30 minutes, to give it a bit of extra time, and I was able to login without any issues. I repeated closing the lid, opening, and re-logging in two more times just to be sure. As of right now, it is working as expected. Even though I did find a work around, it is not something I would expect a normal user to be able to, nor have to, do in order to access their account. After doing some mulling on the issue, I have a notion as to what is happening.

What I think is happening

I think I have an idea as to what is happening. I think when macOS is performing its updates, it is logging back into the same user account that was logged in when the update was started, in my case my mobile account. When this login happens, I think one of the following situations is occurring.

The first possibility it is logging in and not waiting long enough to validate the credentials. The second possibility is that it is logging in with incorrect credentials and locking the account. The third possibility is that the credentials cannot be validated with the Active Directory server after a reboot, because it is not connected via the VPN, so it is locking the account due to trying to connect, but not being able to do so.

The fourth possibility is that macOS is just messing up and falsely indicating that the account is locked, when in fact it is not. In particular, the Login Window process thinks the account is locked and will not allow it to login. I suspect this may be a possibility because I was able to successfully login using Screen Sharing, which should not have been possible if the account was truly locked. Do not get me wrong, I am glad that I was able to login with Screen Sharing so that I could actually login properly.

If the mobile account was indeed locked and I was still able to login via Screen Sharing, then this would be a significant security issue. However, there may be an explanation for this. When I connected with my mobile account via Screen Sharing, I was connected to my office via the VPN using my local administrator account. Since the VPN was active, I think that it may have been able to authenticate with the Active Directory domain, which may have allowed me to login. Although, if the account was locked, it should not have allowed me to login.

Possible Solution?

I do not have a definite solution. However, I think the next time there is an update I may try logging out of the mobile account and using the local administrator account I have instead of using the mobile account and seeing if the mobile account is locked out again.

Closing Thoughts

I am thinking that the root cause is the fact that it cannot connect to the Active Directory server. I think this because of the fact that I do not have any issues with the Mac mini when performing updates. The only difference is that the Mac mini is connected all of the time, whereas the MacBook Pro requires the VPN to connect the Active Directory server.

I am glad that I was able to find a way around the issue. However, I still suspect that the root cause is macOS Big Sur. There have been numerous other reports of this happening. Some are on JAMF, while there are other reports on the Apple Discussion forums, here, here, and here. It does appear as though all of the accounts are Active Directory accounts.

I hope that logging out of the mobile account and using the local admin account will fix the issue, but I will not be able to know for sure until I update to macOS 11.3, or 11.2.2. macOS 11.3 is currently in beta, and will likely be out sometime this spring. Regardless of this being a workaround, Apple needs to figure out how to work around this issue, particularly given that there will be an increasing number of people who are, and will continue to be, working from home.

There is a new release of wwriteLite, version 7.1.0. This is a bug fix release that does include one tweak.

Tweaks

• Requires iOS 14.4.
• Twitter Support username changed to @wwriteLite, The old username of @waynesworkshop will work as well.

Bug Fixes

• Fixed issue where “Always Show Ad” would not necessarily show an ad.
• Fixed an issue where tapping on the “info” icon in an Ad would not show the ad information.

As usual, wwriteLite is free and available in the iOS App Store. If you download it and experience any issues feel free to contact support.

Last week I posted about Apple's Development Transition Kit (DTK), and how they were proving a $200 USD credit that expired at the end of May, 2021. There were some developers who were fine with what Apple offered, while there was a contingent who were a bit miffed at what Apple offered. On Friday, Apple sent an email that states:

Thanks again for participating in the Universal App Quick Start Program. 

We heard your feedback regarding the 200 USD appreciation credit mentioned in our last email. Our intention was to recognize the tremendous effort that you have put into creating amazing universal apps. By partnering with us early, you showed your commitment to our platform and a willingness to be trailblazers. 

So instead of the 200 USD credit that expires in May, we are giving you a 500 USD Apple credit and extending the time you can use it to get a new M1 Mac through the end of the year. If you already purchased a new M1 Mac, the Apple credit gives you the flexibility to purchase any Apple product to help with your app development work. 

We’ll share details soon about how to ship the Developer Transition Kit (DTK) back to Apple. Note that the DTK will no longer receive publicly available software updates after macOS Big Sur 11.2. We encourage you to return it as soon as possible so that your development work is not interrupted. And once you return the DTK, you'll receive your Apple credit. 

Thank you again for making the Mac with M1 launch such a great success. 

As I stated in my post

An alternative to providing an extension would be to extend the length of time that the code can be used. Maybe make it expire at the end of the year instead of the end of May. I am sure that some developers might still not end up using their code, but it would provide a bit more time for some developers to be able to purchase a machine

I am glad to see Apple extending the credit until the end of the year. Not everybody would have the means to purchase an M1 Mac prior to the end of May, depending on their business. Having it extended until the end of the year is definitely better. Honestly, I would have been fine with them just extending the amount, but I am not going to argue with $500 credit for those who had the DTK. In particular, for those whose DTKs stopped working after a few months and did not get any anywhere near the full usage of the devices.

What is even better though, is that if someone did purchase an M1 Mac already, then it can be used for other things to help with their development. I hope Apple ends up releasing a non-XDR monitor, but only time will tell if that actually happens or not.

It is not often that Apple makes the move from one type of architecture to another. For the Mac it has happened a total of three times. Motorola to Power PC in the early 90s, Power PC to Intel, in 2005, and now Intel to Apple Silicon; the last transition began last year with the release of the MacBook Air, Mac mini, and MacBook Pro with the M1 chip. In order to be able to make sure that the hardware and software was ready for users, Apple unveiled a program called the Universal App Quick Start Program. This program was announced on June 25th, 2020 at Apple's World Wide Developer conference.

If a developer applied for, and was subsequently approved, they would be able to receive a Developer Transition Kit, or DTK, machine. The 2020 Developer Transition Kit has the form-factor of a Mac mini and has the follow specifications:

• An 8 -core A12Z (the same processor as the 4th Generation iPad Pro)
• 512GB SSD
• 16GB of RAM
• Two USB-A ports
• Two USB-C ports
• One HDMI port
• One Gigabit Ethernet port
• 802.11AC wireless networking
• Bluetooth 5.0 connectivity

If you were an Apple Developer and you wanted to obtain one of these machines, you had to apply. If you were approved, you would be able to order one for $500. The program came with some stipulations. Some of these include:

• The DTK is Apple's property
• The DTK would need to be returned to Apple.

The program was to last up to one year and Apple would let you know when you needed to return the machine. Apple has begun doing so. Many developers began receiving an email that states the following:

Thank you for participating in the Universal App Quick Start Program and your continued commitment to building great apps for Mac. Response to the new Macs has been incredible, and we love the fantastic experiences developers like you have already created for Mac users.

Now that the new MacBook Air, Mac mini, and MacBook Pro powered by M1 are available, it’ll soon be time to return the Developer Transition Kit (DTK) that was sent to you as part of the program. Please locate the original packaging for use in returning the DTK. We’ll email you in a few weeks with instructions for returning the DTK.

In appreciation of your participation in the program and to help with your continued development of Universal apps, you’ll receive a one-time use code for 200 USD* to use toward the purchase of a Mac with M1, upon confirmed return of the DTK. Until your program membership expires one year after your membership start date, you’ll have continued access to other program benefits, such as Technical Support Incidents and private discussion forums.

This $200 code has some stipulations. The first is that it can only be used towards an M1-based Mac. The second is that the code is only valid until May 31st, 2021.

With the previous transition from PowerPC to Intel, Apple also provided Developer Transition Kits to developers. At that time, when developers returned their machines, they received an iMac. I would not expect Apple to do the same thing this time, for a couple of reasons. The chief amongst these is that Apple is in a different situation this time. They have significantly more developers than before and likely have more 2020 Developer Transition Kits out in the world than in 2005. Secondly, Apple is not going to provide even a base model Mac mini for that price.

At no point did Apple indicate that there would be any sort of compensation for partaking in the program. However, precent did show that they had done it before. As we are all aware, that does not mean that what happened in the past will happen again.

Even with that though, there are a couple of issues as I see them. First, Apple made over $114 billion in revenue last quarter, and over $28 billion in profit. The $200 seems like a jab in the eye of developers, given how much profit that they made just last quarter. This is particularly true given that those who purchased the rental of the DTK helped Apple test and validate that the software and development tools were ready for production.

Second, many developers already purchased M1-based Macs. Having a one-time use code for $200 off of an M1-based Mac is not going to help them with their previous purchases. This means that either developers will end up purchasing another M1-mac, which starts at $700 for the base model Mac mini, or they will let the code expire. Neither of these provides any good will towards developers.

I think it would be great if Apple offered either $200 towards the purchase of an M1-based Mac or an extension to the Apple Developer program. I think this would make the most sense, because developers who already purchased an M1-based Mac would be able get some benefit without having to purchase another machine that they do not necessarily need. For individual developers that extension might be two years, and for enterprise developers it might just be for a year. Even though I like this idea, I do not see it happening. My reasoning for it not happening is the fact that the $200 towards the purchase of a new M1-based Mac only reduces the profits of Apple, but the cost of the machine is still covered. If Apple opted to give an extension, then that is services revenue that they would end up forgoing entirely, instead of just having a bit less profit overall.

An alternative to providing an extension would be to extend the length of time that the code can be used. Maybe make it expire at the end of the year instead of the end of May. I am sure that some developers might still not end up using their code, but it would provide a bit more time for some developers to be able to purchase a machine. What would be a real kick in the pants would be that if the higher-end MacBook Pros are not released until June or July, because then it would really look bad for Apple to not have the true developer machines be purchased by developers. Overall, given how profit-motivated Apple is, as well as how they put developers at the bottom of the list, I do not see them changing anything at all.

There are some developers that are perfectly fine with the $200, because they were not expecting anything. Honestly, that is the best approach to anything when it comes to Apple. Expect nothing, because then when you do get something, it is a big surprise. Ultimately, no matter what Apple does, it will just irk developers and may not generate all that much good will with them. It might have just been better for Apple to not offer anything, but they would get pushback for that approach as well. No matter what Apple decided to do, it would be a catch-22, but that is the burden you take on when you are the richest company in the world.

One of the things that I tend to do often is to listen to audio. This could be podcasts, music, or even audiobooks. Listening to Audiobooks allows me to do multiple things at once, like grocery shopping, playing video games, cleaning, and another tasks.

I generally listen to music when I am not listening to audiobooks or podcasts, and most often while I am working, although I can listen to audiobooks or podcasts as well, depending on what I am working on. If I am doing something that does not necessarily need me to concentrate on programming.

I cannot say why, but I thought I would keep track of the books that I have listened to over the course of the year. With today being February 1st, I figured now is a good time to recap those items that I listened to during January. It should be noted that I listen to audiobooks using the Audible app and generally listen between 1.5x and 2x. Therefore, I get through audiobooks a bit faster than normal. Typically, if it is a title that I have not listened to before, I listen at 1.5x or 1.6x. Whereas, if the title is something that I have listened to before, I will listen to it at 2x.

Over the course of the month of January, I listened to 27 different titles, 12 of them being ones that I listened to for the first time. I do not think I will be able to listen to as many books in February, but only time will tell.

With that, here is everything that I listened to throughout January, in the order that I listened to them.

Disclaimer: the links below will provide a bit of a commission if you purchase anything.

I hope to be able to keep up the record of what I have listened to over the course of the year. I am sure that the number of books that I listen to during the summer will decrease, since I work on my books during the summer.