I get the same.

Our solution as well.

We cant turn off "Prevent Common Passwords" at this time.

At this time, I would like to officially request a custom build.

This is a system-wide problem and affecting many of our users.  Also creating new accounts.

Thank you,

Ron

we got the same issue. please give us a custom build to fix this bug.

"Not a common password" is not a red text warning like the rest of the requirements when a user changes a password.

"Not a common password" warning is missing when a domain admin or server admin changes a password.

Was a custom build pushed for this? If not, we will hold on upgrading.

Waiting for a fix. One of our customer wants to create around 150 new mail boxes.

We will have a fix for this released this morning. It's currently undergoing QC, so should be out shortly.

we updated to build 8622 on Friday - until now no big issues reported today during our first business day with the new build.

except the already mentioned/reported the settings/saving issue - so we are waiting for upcoming fix Derek mentioned already.

We have the password issue resolved but we removed Thursday's release and will release again this week.  There could be a bug related to special characters in folders that can cause missing emails.  Only one customer has brought this to our attention but not knowing what or how it happened, we are being extremely proactive.  The customer who reported the issue has a LARGE number of users but only affected a few users.  More info to come. 

I just wanted to add that this happens when attempting to change a logging level as well.

Tony talked us into downgrading.

We figured out the email folder issue which was the primary reason we had pulled the 8622 build. The issue is VERY uncommon but I'm still glad we pulled the build. 

We included some code in 8622 to fix an IMAP issue with special characters.  That code did its job but it didn't take into account users who had another folder called INBOX.  We're not sure how users were able to create these but our fix didn't take that into account because it shouldn't have been allowed.  We had a couple customers upgrade to 8622 that had a few users with this scenario.  

This issue was clearly concerning enough that we wanted to be on the safer side and pull the build.  The settings issue we had was another reason and the combination just made pulling it, the right choice.

One of these issues was very obscure but the settings issue should never have slipped through QC.  The amount of tests and efforts we make before release are why we have so many good releases, this settings issue needs us to re-evaluate interface steps before release because that super bothers me!

Wanted to give an update, a new build will be ready on Thursday.  

Sounds awesome Tim!! Thanks for the update.