Office 365 & Live@EDU – Disable Mailbox

Takeaway

Microsoft has confirmed that the “Disable Mailbox” feature is broken (at least in Live@EDU; I’m assuming in Office 365 as well); I advise against using it, until further notice.

Disable Mailbox Functionality

If you’re familiar with Active Directory or Microsoft Exchange, you probably know of the “disabled/enabled” status that you can assign users. When it comes to Exchange Online (your tweaked Exchange 2010 hosted by Microsoft as Live@EDU or in Office 365), there’s no concept of “disabled mailbox” – no GUI options either. However, there’s this PowerShell command:

Set-CASMailbox <Identity> -OWAEnabled $false 
   -PopEnabled $false -ImapEnabled $false 
   -MAPIEnabled $false -ActiveSyncEnabled $false 
   -EwsEnabled $false

…as you can see, it’s a bunch of individual functionality switches that get turned off, to achieve the “disabled mailbox effect.”

Issue Background

I implemented an Active Directory -> Live@EDU synchronization system for a large school district in Texas; part of that system was provisioning of the AD disabled/enabled status into Live@EDU (i.e. if a kid gets suspended, they lose email, but with possibility of getting it back). I used Tools4ever‘s UMRA and here’s what my action looked like, after I plugged the PowerShell command into UMRA:

The system worked fine for a while and it wasn’t until the last months of 2012 that we started getting errors. I suspect this could have something to do with Microsoft phasing out the Live@EDU system.

Error and Microsoft Response

The most intelligible PowerShell error we got is this:

The value ‘OWA§1’ is already present in the collection

Some Googling revealed that we weren’t the only ones dealing with it, but did not give me a solution. My Client ended up contacting Microsoft Enterprise Communications Support and the response we got was:

“The error believed to be a known issue pending fix in the datacenter. […] Yes, indeed this is a known issue.”

No workaround was available at the time of this writing.

Tools4ever SSRPM Error 1329

Recently I came across an SSRPM Client in the military business who was getting Error 1329 when trying to enroll accounts over the website. SSRPM of course is the Self Service Reset Password Management – Tools4ever‘s take on the “what’s your mother’s maiden name” type of authentication.

Log On To

The investigation and resolution of this brought me to a rather cool feature of Active Directory I have never worked with before – restricting which computers a user is allowed to log on to, as a property of the actual user account:

 

Investigation

Any non-negative SSRPM error codes are simply error codes of the underlying systems (i.e. Active Directory) that are bubbled up through the error message.

A little bit of Googling on the error code reveals:

• 80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 531, v893
• HEX: 0×531 – not permitted to logon from this workstation
• DEC: 1329 – ERROR_INVALID_WORKSTATION (Logon failure: user not allowed to log on to this computer.)
• LDAP[userWorkstations: <multivalued list of workstation names>]
• NOTE: Returns only when presented with valid username and password/credential.

Conclusion

Long story short, some years ago they utilized this Log On To feature of AD to really lock down the system and since then have stopped, but the settings remained on many AD accounts.  As a result, certain users would be running into this error when the SSRPM server was not in the list of computers they were allowed to login to. Fix is easy: either map the SSRPM server out explicitly in the Log On To list, or don’t utilize the Log On To feature.