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

How to connect to Exchange Online with PowerShell

I realized that my previous post might have been confusing about how to connect to Exchange Online. So I wanted to do a post on how you can connect to Exchange Online Using PowerShell.

First things first, because some of the scripts that you will need to run are not native to your machine, you will need to run this command, probably as an administrator before you can try to connect.

Set-ExecutionPolicy RemoteSigned

Next you will need to set your login credentials. This account needs to have administrative privileges in Exchange Online for it to Connect:

$UserCredential = Get-Credential

This will bring up a Office 365 login prompt. Enter your username, then your password and when it is done the screen will close and you will be back in PowerShell
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Lastly you will need to run this command

Import-PSSession $Session -DisableNameChecking

Which will enable several commands that are now available to you.
I hope that this guide helps you, I know that I always forget how to do this so doing a Blog post should help. 
Please feel free to share with your friends if you think it will help them. 
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.

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.

Install Exchange 2013 SP1

I don’t know about you but I really like where Microsoft is going with their installers these days. Back when I first stated in the field and had to install Exchange 2007 there were so many prerequisites that needed to be installed before you could even start to do the installation. They have now made it to where the system will at least tell you which items you need to install rather than send you on a wild goose chase. 
I started this particular post as documentation notes for an Exchange Server that I stood up in my Lab at work. Originally it was not meant to be a functioning Exchange server but as time went on it evolved into one. 
I am going to skip all of the previous steps about how to setup and configure your Server installation. However if you need instructions on that you can find it here:
How to build a Server 2012 R2 Server
We start with having the installation files mounted to the CD/DVD Drive.
Double Click on the blue Exchange 2013 Icon to launch the Wizard.

Of course if you at User Account Control (UAC) enabled you are going to get this message. Click Yes to continue.

Checking for Updates is optional but I always like to make sure that I am working with the latest version of the software to avoid issues (unless there is a known issue).

Once the updates check is complete you can click Next to continue.

Now you just need to be patient until the files are copied to the proper working directory or install directory. Once that completes you then have to wait while the setup is initialized.

Once all of that is done you can begin the installation by clicking Next.

Accept the licensing agreement and click Next.

You will now be presented with the option to use or not use recommended settings. For this server I went with recommended. Click Next to continue.

You will now get to choose your Server Roll Selections. The most common roles for the kind of server that I am working with here would be Mailbox role, Client Access role (not sure why they are not checked off in this image.) Click Next to Continue. 

Here you can decide what directory you would like to install the Exchange application. This also includes the default mailbox stores. Click Next to continue.

Next you have the opportunity to name your organization. You are only able to do this once and you are only presented with this screen if you do not have exchange running in your environment at all. Click Next to continue. 

If you so choose you can enable Malware protection setting which allows Exchange to scan for Malware in your emails. For me I chose no as we have other products we use for that, and this server is not accessible from the internet for email. Click Next to Continue. 

Now with all of those configurations behind you, it is now time for the readiness check. Click Install to begin. 

Once the readiness check is complete you may be presented with items that need to be resolved before you can continue. Once you have them all taken care of you can

As you can see all of the issue have now been resolved and you can now click Install to continue. 

Once you click install the setup pretty much runs unattended until it completes. If you do what I did and go out to lunch instead of taking more screenshots you may just skip all the waiting and see my next screenshot.

As you can see the installation completed and you are now ready to launch the Exchange Admin Center by clicking the check box and clicking finish.

Once you click Finish on the previous Screen Internet Explorer (or your default web browser is opened) and you are now able to log in.

Please let me know if you found this helpful in the comments below. This was a rather large guide and I paired down a few things to keep it where it is.