Feedback by UserVoice

Juho Lehto

My feedback

  1. 187 votes
    Vote
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    12 comments  ·  General  ·  Flag idea as inappropriate…  ·  Admin →
    Juho Lehto commented  · 

    I am responsible for producing automation tools for our clients and this is one of the major stumbling points in our automation tools.

    Up until now we've had following process:
    1) Create a new mailbox to on-premises Exchange with New-Mailbox-cmdlet and Shared-switch.
    2) Manually run Directory Syncronization and wait for the user to appear in the cloud.
    3) Start a move request from on-premises to Office 365 with New-MoveRequest-cmdlet.
    4) Wait for the move request to complete and then remove the move request.

    Can I just say that while this process works, it takes unnecessarily long to complete compared to creating equipment and room mailboxes straight with New-RemoteMailbox-cmdlet.

    Our Office 365 project people decided that with the switch to the new AADS, we no longer could manually run directory synchronization. This threw a major wrench into creating shared mailboxes, which is pretty much the only thing that requires manual synchronization to work as a part of process automation,

    The only option here is to add additional monitoring process to see when user object has been synced to the cloud and then start and finish the move request. Even if shared mailboxes were to be created as resource mailboxes, they still need to be changed to shared mailboxes after user and mailbox objects have been synced to the cloud.

    It is unbelievable that not even Exchange 2016 has Shared-switch for New-RemoteMailbox cmdlet. Can you pretty please do something about this and update Exchange 2010-2016 cmdlets accordingly.

    Juho Lehto supported this idea  · 

Feedback and Knowledge Base