Categories
Exchange Microsoft Office 365 PowerShell

Enable a Remote Mailbox in Office 365

So I recently ran into an issue where I had a user who’s Local AD account had been deleted but their Office 365 Mailbox was still showing up. We tried to bring the user account back, however the AD recycle bin was not enabled. So we had to create a brand new account for the user and then work from there.

We originally planned to create a new mailbox and let the user start from scratch. However we ran into an issue were the old mailbox would not go away, and it was preventing us from migrating a new mailbox into Exchange Online for the user.

I then found the following Exchange Management Shell command which will allow you to connect the local AD account to the Exchange Online Mailbox.

Enable-RemoteMailbox USERNAME -RemoteRoutingAddress [email protected]

After running the command the user is now able to log in with their new AD account and have access to their mailbox.

I hope you found this post helpful, and if you did, please share it with your friends.

Categories
Exchange Microsoft Office 365 PowerShell

How to convert a User Mailbox to a Shared Mailbox in Exchange 2016

So I discovered that there is the right way and the wrong way to create a Shared Mailbox when using Office 365 Exchange Hosted and Exchange 2016 in a Hybrid configuration. So the way I would normally do it would be to migrate the mailbox to Office 365 and then click that pretty little button to convert to a Shared Mailbox.

It turns out that when you do that it will create the mailbox as a shared mailbox, however the Active Directory (AD) Components are non-existent. Which means you cannot assign permissions to users who are synced by AD.

Well…. you can…. but it doesn’t actually work.

So what can we do to make it work when you have a user who is complaining that they need to send out a file at 4:45 PM on a Friday???

Well there is not much that you can do, but I would start with converting the mailbox back to a normal user mailbox and then migrate the mailbox back to your Local Exchange Environment.

Once the migration is complete you can then run the following command to convert a normal user account to a Shared Mailbox on Exchange.

Set-Mailbox AJones -Type shared

Once the command is complete (which is really freaky fast) you will then be able to see the mailbox under the “Shared Mailbox” section in Exchange.

I would then Migrate the mailbox back to Office 365 the way that it is and once it is done you should be good to go.

In the event that you would want to switch the Shared Mailbox back to a normal mailbox, here is the command to switch it back.

Set-Mailbox AJones -Type regular

I hope you found this guide helpful, and if did, please share it with your friends.

Categories
Exchange Microsoft Office 365 PowerShell Windows

Office 365 Hybrid – Shared Mailboxes Created in Exchange Online do not appear to users whose mailboxes exist on local Exchange

I have been working on an Hybrid Exchange Solution using Office 365. The Client has several shared mailboxes and I wanted to see if a Shared Mailbox created in Office 365 would appear for users who have not been migrated.

Long Story short, the answer is no, they cannot. The reason for this is actually pretty simple. Anything created in Office 365 is not assigned a GUID by Active Directory (because we are only doing a unidirectional sync) so Exchange does not have any record of it.

 It turns out however, that if you migrate the mailbox to the On Premise Exchange server a GUID can be assigned.

I found this Article on Microsoft’s support site on how to do it:
https://support.microsoft.com/en-us/help/3129334/users-in-a-hybrid-deployment-can-t-access-a-shared-mailbox-that-was-cr

Here is the process that you would need to follow in order to get it to work

Please note, the website says that you do not need to do this if your are running Exchange 2016 CU 10 or later. The Client was running 13 at the time, however these steps did work.

  1. Convert the shared mailbox to a regular mailbox by using the Exchange admin center in Exchange Online. To do this, follow these steps:
    1. Open the Exchange admin center in Exchange Online.
    2. Click recipients, and then click shared.
    3. Select the shared mailbox, and then click Convert.
    4. On the Warning page, select Yes to convert the shared mailbox.
  2. Create an on-premises object for the cloud mailbox by using the New-RemoteMailbox cmdlet in the Exchange Management Shell.

    Note This object must have the same name, alias, and user principal name (UPN) as the cloud mailbox.
  3. Set the ExchangeGuid property on the new on-premises object that you created in step 2 to match the cloud mailbox. To do this, follow these steps:
    1. Connect to Exchange Online by using a remote session of Windows PowerShell.
    2. Use the Get-Mailbox cmdlet to retrieve the value of the ExchangeGuid property of the cloud mailbox. For example, run the following command:

      Get-Mailbox <MailboxName> | FL ExchangeGuid 
    3. Open the Exchange Management Shell on the on-premises Exchange server.
    4. Use the Set-RemoteMailbox cmdlet to set the value of the ExchangeGuid property on the on-premises object to the value that you retrieved in step 3b. For example, run the following command:
      Set-RemoteMailbox <MailboxName> -ExchangeGuid <GUID>
  4. Wait for directory synchronization to occur. Or, force directory synchronization.
  5. Make sure that the Office 365 user object is displayed as “Synced with Active Directory.”
  6. Move the mailbox from Exchange Online to the on-premises environment.
  7. Convert the mailbox to a shared mailbox by using the Set-Mailbox cmdlet in the Exchange Management Shell. For example, run the following command:
    Set-Mailbox <MailboxName> -Type Shared
  8. Move the mailbox from the on-premises environment to Exchange Online.
I hope you found this guide helpful, and if you do please tell your friends.

The Woes of being a SysAdmin…..

So last night I was called into our Data Center due to an outage. Once everything came back up we noticed an issue with our Exchange Archive Server which lives at that Data Center. From outlook we were not able to access our In-Place Archives, however we could do it from OWA (Weird Right?)

This morning I looked into the issue further and when I tried to open the Exchange Management Shell on that server I got this message 3 times.

New-PSSession : [ServerName.domain.local] Connecting to remote server ServerName.Domain.local failed with the following error
message : [ClientAccessServer=ServerName,BackEndServer=ServerName.Domain.local,RequestId=2de56d73-34a8-46a9-9bdd-5c023e960cb5,
TimeStamp=8/6/2018 3:14:08 PM] [FailureCategory=Cafe-SendFailure]  For more information, see the
about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ New-PSSession -ConnectionURI “$connectionUri” -ConfigurationName Microsoft.Excha …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotin
   gTransportException
    + FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed

So I tried to google this error message and let me tell you, if you try, good luck. There was literally no information about it. I then ended up googling this part of the message:

FailureCategory=Cafe-SendFailure

This let me to a Microsoft Answers thread which guided me to look at another blog which then said to check the SSL Binding on both the Website and Exchange Back end in IIS on the host. I discovered the the Exchange Back end did not have a binding for port 444. So I pointed it to the proper certificate and after and IIS reset it worked like magic.

Clients are not receiving emails from Exchange

So I had a client call in today and say that they are not receiving emails. That is as descriptive as it gets sometimes, so the first thing I did was check their Mail Gateway which caches email if their Exchange server is not running. So I looked and there is nothing in the queues, so that tells me that things are making it’s way to Exchange.

I then go and open the Exchange Management Shell which will tell me really quickly if the problem is what I think it is. So I fire it up and here is what I get

Note: If you try to open the web console you may have similar issues.

Having seen this message before with this particular client I know now that I have a time sync issue on my hands.

The First thing I look at is the time on the Exchange server.

Then I check the time on one of the Domain Controllers which is the PDC Emulator.

Then I check one of the other Domain Controllers and I find this.

As you can see the time difference is greater than 5 minutes which will cause your Exchange Server to be very unhappy.

Once you fix the time issue you can then try to reopen the Exchange Management Shell and you will see that you can connect without an issue.

Let me know if this was helpful by leaving a comment below.

thank you

Exchange 2016 Back pressure issue

So my biggest challenge over the last few months is dealing with an Exchange 2016 server that keeps having issues with Back pressure. I have never heard of this as a thing before but I have been working on a resolution which has been very very time consuming. I hope to do a post about it soon to discuss it more once this is behind me.

Exchange 2016 – Powershell Virtual Directory not working

So one of the projects that I have been working on lately is to setup a Mobile Device Management (MDM) solution for my company. One of the requirement to get email to Sync for the mobile devices was to connect the MDM server to our internal Exchange 2016 server using PowerShell.

One of the issues that I had been running into for a few days was that the MDM was not able to authenticate to our Exchange Server. I went through everything I could think of to fix this issue and to get it working (Check Firewall ports, SSL Certificates, User Permissions) but nothing was working. Then I remembered back to an post I did on here before about Active Sync and how I had to use a PowerShell command to recreate the Virtual Directory with the correct URL at the time of creation otherwise it will cause PowerShell to fail when you try to connect to it externally.

Well the funny thing about this whole situation is that during my troubleshooting I had to remove the PowerShell virtual directory in order to recreate it. Well… It turns out when you remove the PowerShell directory it also disconnects your PowerShell session to the Exchange server. Now fortunately I have a second Exchange server on the same Domain so I was able to run the command to create a new PowerShell Virtual Directory on that server and after turning off the Require SSL check box I was able to connect to the server again. Also my connection to the MDM Server was working as well!!!

Here is the command s that I should have used to create the PowerShell Virtual Directory.

To Remove the PowerShell Virtual Directory:

Remove-PowerShellVirtualDirectory “Powershell (Default Web Site)”

To Create the New Virtual Directory:

New-PowerShellVirtualDirectory -Name Powershell -RequireSSL:$False



To Reset IIS

IISRESET /noforce

Exchange 2016 – Issue with changing URL for MAPI connections

As you know when you installed Exchange all of the Virtual Directories use the FQDN of the server as the URLs for the Exchange Virtual Directories. If your Exchange server is being used for OWA or CAS you will most likely have a SSL Cerfiticate to prevent you from getting those pesky SSL errors.

During an install that I recently did I ran into an issue where all the outlook clients were getting SSL pop up messages that looked like this:

From the message you are able to see that the name of the certificate does not match the server name. So I logged into the Exchange Admin Center and looked under Servers > Virtual Directories and checked each of the Virtual Directories listed. As this was my first 2016 installation I discovered that there was a virtual directory for mapi. So from the web interface I changed the internal url to match the name of the certificate “https://Mail.Domain.com/mapi” and restarted IIS. After that I go and try and configure an outlook client and good news I no longer get the SSL Error, but now I am unable to authenticate to the mailbox!!!

After playing around with it for a while I discovered that changing the name back did not fix the issue so I was forced to do a rebuild on the virtual directory and that took me back to square 1.

After hours of searching online for an answer I found this powershell command that worked

Set-mapivirtualdirectory -identity “[SERVERNAME]mapi (default Web Site)” -internalurl  https://Mail.DOMAIN.com/mapi

After doing this command I restarted IIS again and the clients are now able to connect without issue.

UPDATE on this issue:

I would appear that do to a misconfiguration in the client’s internal DNS their Autodiscover.domain.local was a A record and not a CNAME which it appears that outlook autodiscover does not like. So I changed the record to a CNAME by deleting the A record and recreating it. Then I went to a local machine and did a IPCONFIG /FLUSHDNS and then restarted outlook and that seems to have fixed the issue.