locked
set msExchUserAccountControl to 2 - based on a query of disabled users in AD RRS feed

  • Question

  • I have a problem that even though user account are disabled in AD, the msExchUserAccountControl value is not automatically set to 2-  Can anyone help me with a powershell query that will update the value of that attribute to 2 based on disabled accounts in AD?

    I saw the article with this command:  Set-ADUser -Identity "<user name or DN>" -Replace @{msExchUserAccountControl="0"}

    But we have thousands of accounts.  I want to filter <username or DN> with all disabled users.

    Thanks!

    Friday, July 5, 2019 4:01 PM

All replies

  • Please read this first:  This forum is for scripting questions rather than script requests.

    Also find scripts here:  PowerShell Gallery or here:  TechNet Gallery - resources for IT professionals.

    Learn PowerShell:  Microsoft Channel 9 - Getting Started with Microsoft PowerShell 3.0.

    Script requests: Microsoft Technet Script Center - Requests.

    It is crucial that you understand at least the basics of Powershell to avoid big mistakes with your infrastructure. If you don't it would be better to hire a trained IT professional to do what you need.

    With Search-ADAccount you can find diesabled accounts and with Set-ADUser you can change existing attributes. Please, always read the complete help including the examples to learn how to us the cmdlets.


    Live long and prosper!

    (79,108,97,102|%{[char]$_})-join''

    Friday, July 5, 2019 4:17 PM
  • I just dont know the power shell formatting well enough, but it would be Something like:

    if>userAccountControl=514 or 66050

    then>Set-ADUser -Identity "<username>" -Replace @{msExchUserAccountControl="2"}

    Friday, July 5, 2019 4:20 PM
  • Hmm  would this do the trick?  

    Set-Variable-Name"USERNAME"-Value(Search-ADAccount-AccountDisabled)-Scopeglobal -PassThru| Set-ADUser -Identity "USERNAME" -Replace @{msExchUserAccountControl="2"}

    Any advise would be much appreciated!

    Friday, July 5, 2019 4:38 PM
  • If the account is disabled in AD then it is also disabled in Exchange.  The Exchange value does not need to be set. The operation is automatic.


    \_(ツ)_/

    Friday, July 5, 2019 6:32 PM
  • That's true, but IIRC, the Exchange information store uses the msExchUserAccountControl to determine whether to read permissions using the objectSID (or an enabled user) or the msExchangeMasterAccountSID (for a disabled user).

    This was important with earlier versions of Exchange when the ADUC and RUS were dealing with user accounts in NT and the AD (and before the introduction of the AD cmdlets).

    In any case, setting the value to "0x2" instead of just turning on the corresponding "ACCOUNTDISABLE" bit would be a mistake (unless you're sure that all the other bits were already zero.


    --- Rich Matheisen MCSE&I, Exchange Ex-MVP (16 years)

    Friday, July 5, 2019 7:00 PM
  • The number is a number and not a string. Using a string can create issues.

    Search-ADAccount -AccountDisabled | Set-AdUser -Replace @{msExchUserAccountControl=2}


    \_(ツ)_/

    Friday, July 5, 2019 7:57 PM
  • If you need to preserve state then this will work but it will be slow.

    Search-ADAccount -AccountDisabled | 
        ForEach-Object{
            $msExch = (Get-ADUser $_ -Properties msExchUserAccountControl).msExchUserAccountControl
            $flags = $msExch -bor 2
            Set-AdUser $_ -Replace @{msExchUserAccountControl=$flags}
    }
    Test carefully on a lab system.


    \_(ツ)_/


    Friday, July 5, 2019 8:06 PM
  • I have never found that value et to other than 0 or 2.

    Setting it to 0 effectively disconnects the mailbox.  Reading in the user context would then make no sense so the EX must use the master account to read the mailbox.

    I think this was all changed after 2010.


    \_(ツ)_/


    • Edited by jrv Friday, July 5, 2019 8:15 PM
    Friday, July 5, 2019 8:15 PM
  • I haven't touched Exchange or Servers since retiring five years, so details are fading fast. :-)

    However, a "Resource" mailbox (i.e., one that is attached to a user that's never expected to log in) would be connected to a disabled user, so the msExchangeAccountControl should have the 0x02 bit turned on in that case.

    I don't remember ever seeing any other bits turned on, either (none of them would make sense for Exchange to use) . . . but see the first line of this reply.

    I was always leery of using direct AD object manipulation on anything in the AD that was in any way mail-related. Exchange has the necessary cmdlets to deal with that stuff so I didn't have to worry about it.


    --- Rich Matheisen MCSE&I, Exchange Ex-MVP (16 years)

    Friday, July 5, 2019 9:26 PM
  • I agree.  There was an issue before 2010 or through early 2010 where this bit needed to be set through D but that was fixed.  Exchange after 2010 always manages this as needed including for resource and other special purpose mailboxes.  The actual setting of the bit in AD is legacy and has little to do with modern exchange. It seems to have been retained because many sites used old Exchange servers (2003/2010) for a very long time.  It appears that MS is finally doing what it should have done and is making sure that Exchange manages all of its AD attributes fully.

    I also saw a number of blogs (Exchange Team and MS) noting that the Exchange Cmdlets now manage all things Exchange.  AD is only a shared data base for user information needed by both AD and Exchange  which leads me to believe that Exchange will soon be running on Linux and other Unix flavors just like SQLServer.


    \_(ツ)_/

    Friday, July 5, 2019 9:59 PM
  • They've tried using SQL databases in the past, but they've never been able to get the performance they need to manage all the data in all the mailboxes once the started scaling up the mailboxes/server numbers (I remember when it was 256/server). SQL works best when the data are "rectangular". The data in messages isn't at all in any "regular" format (thank you, MAPI). Unless they port the ESE (JET Blue? Red? I forget) to *nix they'll be sticking to Windows servers.

    Exchange has always had the cmdlets it need to manage MS Exchange (it was the first application to use the AD and Powershell). In the early days of Exchange 2000 and the AD (during the Joint Development Program) we had to do quite a bit with Visual Basic (I used Perl instead) and ADSI to manage (or at least report) the contents of the AD.


    --- Rich Matheisen MCSE&I, Exchange Ex-MVP (16 years)

    Saturday, July 6, 2019 1:58 AM
  • I didn't mean that SQLServer was used for Exchange only that SQLServer has been ported to Unix and that Exchange will likely be decoupled from AD and ported to Unix or just plain virtualized as an SOA version.  MS seems to be moving everything to SaS/SOA. Windows is now touted as WaaS and the virtual desktop has been released in preview.  The OS and tightly integrated services are passing. 

    The Cloud has changed everything and has made the OS obsolete.  Soon the end points will be hardware only.  "No user serviceable parts inside".  No need for techs at the endpoint, all systems managed from the cloud with AI assisted systems.  The computer tech is now obsolete and will soon be just a memory.

    Currently the cloud systems are all in lights-out buildings that are attended by only robots (see YouTube videos) and all maintenance is done remotely by automated systems.  Parts are delivered and replaced by robotic systems.  MS is now experimenting with sinking the service centers under the ocean off the coast of California.


    \_(ツ)_/

    Saturday, July 6, 2019 5:48 AM
  • Hi,

    Was your issue resolved?

    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,

    Lee


    Just do it.

    Wednesday, July 31, 2019 8:30 AM