Here's a scenario I've seen quite often:
You have a Shared Mailbox called Human Resources (hr@exchangeitup.com), and you've added an alias of training@exchangeitup.com.
One of the user's with Full Access to the HR Mailbox, wants to create an inbox rule that will move messages sent to the training address to a Training folder - but this won't work.
When messages are sent to an alias, Exchange Directory Services will "translate" the alias as the primary email address; Training = Human Resources, and you can see it action by typing the address in the "To" field in Outlook and watch it change to the primary name. Therefore, inbox rules won't work for sorting/moving those emails to the alias.
In order to get around that behavior, we'll need to create a Mail Contact and a Transport Rule:
1. Remove the alias from the Shared Mailbox by running the following cmdlet in the Exchange Management Shell (EMS):
Set-Mailbox "Human Resources" -EmailAddresses @{remove="training@exchangeitup.com"}
Give it a few for Exchange/AD to update.
2. Create a Mail Contact for "Training" by running the following cmdlet:
New-MailContact -Name "Training" -ExternalEmailAddress training@exchangeitup.com -OrganizationalUnit “Contacts”
**Note** This is re-using the secondary email address taken away from shared mailbox in step 1. Change the Name, External Email Address, OU match your environment.
3. Create a Transport Rule to redirect all messages sent to the Training Contact over to the HR Shared Mailbox:
In the Exchange Admin Center (EAC), navigate to mail flow > rules.
Create a new Rule with the following settings:
Name: Training Forward
*Apply this rule if...
The recipient is..."Training"
*Do the following...
Redirect the message to..."Human Resources"
Or you can use the EMS to run the cmdlet:
New-TransportRule, parameters -SentTo ("Training") -RedirectMessageTo ("Human Resources") -Name "Training Forward" -StopRuleProcessing "False" -Mode "Enforce" -Comments "" -RuleErrorAction "Ignore" -SenderAddressLocation "Header"
4. Create an inbox rule for the HR Shared Mailbox to move emails sent to the Training Contact to another folder in the Shared Mailbox:
In OWA, click your person icon in the upper-right corner, then select Open Another Mailbox.
Search for and open the Shared Mailbox (Human Resources in this example).
Then click the Settings Gear in the upper-right and go to Options > Inbox and sweep rules > create a rule using the following settings
It was sent to..."Training"
Do all of the following:
Move the message to folder..."Training Folder"
Now test it out! Send a message to training@exchangeitup.com and verify that the message was moved directly to the Training Folder.
Showing posts with label OWA. Show all posts
Showing posts with label OWA. Show all posts
Sunday, June 23, 2019
Saturday, August 11, 2018
Exchange - OWA TimeZoneException Error
Here's an easy one today: Users sometimes get the "Time Zone Exception" error below when logging in to OWA, and it all depends on the web browser their using:
X-OWA-Error: SDServerErr;Microsoft.Exchange.Services.Core.Types.TimeZoneException
X-OWA-Version: 15.1.1531.3
X-FEServer: MBX1
X-BEServer: mail.exchangeitup.com
I've never seen this error happen in IE, but very often in Chrome and Firefox. This is due to the way those two browsers implement adblock, which doesn't handle OWA very well.
We don't want to disable adblock completely, since it is useful, but we'll turn it off for OWA.
In Chrome:
Navigate to OWA, then click “Secure” to the left of the URL.
**Note** It might show an "i" info bubble instead of Secure, if you aren't redirecting OWA to SSL - which you really should do.
Find the “Ads” entry, then choose Allow in the menu.
Now, OWA won't be blocked, but other sites will still block ads as normal.
In Firefox:
Browse to OWA and click the shield icon next to the URL to bring up the Control Center.
In the Control Center, click Disable protection for this session.
Once Tracking Protection is disabled, a shield icon with red strikethrough (which means tracking protection is off) will appear in your address bar.
If you need to do this on a lot domain machines, there are GPO templates, but I haven't dove into them to see what you can control...there might be a way to set the adblock exclusions for OWA if you wanna check them out.
For Chrome, grab them here
For Firefox, grab them here
You could also just disallow those browsers and force IE, but that's up to you, and it of course wouldn't have any affect on non-domain computers.
X-OWA-Error: SDServerErr;Microsoft.Exchange.Services.Core.Types.TimeZoneException
X-OWA-Version: 15.1.1531.3
X-FEServer: MBX1
X-BEServer: mail.exchangeitup.com
I've never seen this error happen in IE, but very often in Chrome and Firefox. This is due to the way those two browsers implement adblock, which doesn't handle OWA very well.
We don't want to disable adblock completely, since it is useful, but we'll turn it off for OWA.
In Chrome:
Navigate to OWA, then click “Secure” to the left of the URL.
**Note** It might show an "i" info bubble instead of Secure, if you aren't redirecting OWA to SSL - which you really should do.
Find the “Ads” entry, then choose Allow in the menu.
Now, OWA won't be blocked, but other sites will still block ads as normal.
In Firefox:
Browse to OWA and click the shield icon next to the URL to bring up the Control Center.
In the Control Center, click Disable protection for this session.
Once Tracking Protection is disabled, a shield icon with red strikethrough (which means tracking protection is off) will appear in your address bar.
If you need to do this on a lot domain machines, there are GPO templates, but I haven't dove into them to see what you can control...there might be a way to set the adblock exclusions for OWA if you wanna check them out.
For Chrome, grab them here
For Firefox, grab them here
You could also just disallow those browsers and force IE, but that's up to you, and it of course wouldn't have any affect on non-domain computers.
Saturday, December 16, 2017
Exchange - Disable OWA Externally With Kemp
{rant} In my organization, we have some "project managers" who have very little understanding of Exchange and therefore come up with policies that don't make any sense at all, like disabling OWA externally. To make matters worse, they're not even project managers for my US Exchange environment; they're located in the European HQ, which has it's own Exchange forest.
Even after presenting whitepapers and articles showing that OWA has a very small attack surface, and the Exchange servers aren't directly behind OWA (the reverse proxy is) they still want it disabled...stupid {end-rant}
I've seen this question tons of times on forums and some of the answers go to extreme lengths like:
- Setting up separate virtual directories in Exchange with new IPs and DNS (that's way too much work)
- Setting firewall rules to block IPs (this is a bad idea, especially if you federate with another organization, as it will almost certainly break your free/busy sharing)
If you run a Kemp LoadMaster (or any load balancer for that matter) the solution is pretty simple:
Disable the OWA SubVS on the External Arm.
On your LoadMaster, navigate to:
Virtual Services > View/Modify Services > Your External Arm
Click the Modify Button in the right-pane:
Scroll down and expand SubVSs.
On the OWA row, click the Disable button under the Operation column on the right:
It will show Disabled under Status
Now browse externally to your OWA site and you'll get:
**Note** This will also disable external EAC access. So tell your IT security trolls (who came up with the not-so-brilliant idea to disable everything) that if an emergency occurs, you'll have go to your computer, connect to the VPN, log into the EAC, and fix what broke...there will be no more instant support.
On the positive side, free/busy, federation, ActiveSync, and Outlook Anywhere will still function properly.
Even after presenting whitepapers and articles showing that OWA has a very small attack surface, and the Exchange servers aren't directly behind OWA (the reverse proxy is) they still want it disabled...stupid {end-rant}
I've seen this question tons of times on forums and some of the answers go to extreme lengths like:
- Setting up separate virtual directories in Exchange with new IPs and DNS (that's way too much work)
- Setting firewall rules to block IPs (this is a bad idea, especially if you federate with another organization, as it will almost certainly break your free/busy sharing)
If you run a Kemp LoadMaster (or any load balancer for that matter) the solution is pretty simple:
Disable the OWA SubVS on the External Arm.
On your LoadMaster, navigate to:
Virtual Services > View/Modify Services > Your External Arm
Click the Modify Button in the right-pane:
Scroll down and expand SubVSs.
On the OWA row, click the Disable button under the Operation column on the right:
It will show Disabled under Status
Now browse externally to your OWA site and you'll get:
**Note** This will also disable external EAC access. So tell your IT security trolls (who came up with the not-so-brilliant idea to disable everything) that if an emergency occurs, you'll have go to your computer, connect to the VPN, log into the EAC, and fix what broke...there will be no more instant support.
On the positive side, free/busy, federation, ActiveSync, and Outlook Anywhere will still function properly.
Saturday, February 18, 2017
Exchange 2016 Room Mailbox Calendars Only Showing Busy
We recently migrated from Lotus Notes to Exchange 2016 and after moving Rooms and Equipment Mailboxes over, some of the calendars didn't keep their permissions.
When users went to schedule a room they wouldn't see who had booked the room, they would only see "Busy" like in this example:
This was strange because I left the default settings of AddOrganizerToSubject and DeleteSubject set to "True" so users should be able to see the organizer of the meeting.
After some digging around, I found that the Mailbox Folder Permissions for the "default" user were set to "none"...but not on every Room mailbox. Looks like the migrator tool wasn't able to keep those permissions intact.
To view permissions on a Mailbox fire up the Exchange Management Shell and run:
Get-MailboxFolderPermission "room 1:\Calendar"
**Note** Change "room 1" to the room mailbox name in your environment.
In my case permissions were like so:
Luckily with PowerShell, this is an easy fix. We're gonna set permissions on all Room Mailboxes, so we don't have to go digging through each of them.
**Note** You might get a bunch of yellow warnings saying no changes were made on some Mailboxes; that's ok, it just means the perms were already set.
In the (EMS) and run the following cmdlets:
$r = Get-Mailbox -RecipientTypeDetails RoomMailbox
$r | %{Set-MailboxFolderPermission $_":\Calendar" -User Default -AccessRights LimitedDetails}
**Note** I chose "LimitedDetails" because I don't want users seeing everything about meetings in case they might be sensitive like "we're closing down your office". You can set different levels of access, which are listed in this TechNet article.
Now open a Room Calendar in Outlook or OWA, and you should see the Organizer and Room:
Now you'll have happy users!
When users went to schedule a room they wouldn't see who had booked the room, they would only see "Busy" like in this example:
This was strange because I left the default settings of AddOrganizerToSubject and DeleteSubject set to "True" so users should be able to see the organizer of the meeting.
After some digging around, I found that the Mailbox Folder Permissions for the "default" user were set to "none"...but not on every Room mailbox. Looks like the migrator tool wasn't able to keep those permissions intact.
To view permissions on a Mailbox fire up the Exchange Management Shell and run:
Get-MailboxFolderPermission "room 1:\Calendar"
**Note** Change "room 1" to the room mailbox name in your environment.
In my case permissions were like so:
FolderName : Calendar
User : Default
AccessRights : {None}
Identity : Default
IsValid : True
Luckily with PowerShell, this is an easy fix. We're gonna set permissions on all Room Mailboxes, so we don't have to go digging through each of them.
**Note** You might get a bunch of yellow warnings saying no changes were made on some Mailboxes; that's ok, it just means the perms were already set.
In the (EMS) and run the following cmdlets:
$r = Get-Mailbox -RecipientTypeDetails RoomMailbox
$r | %{Set-MailboxFolderPermission $_":\Calendar" -User Default -AccessRights LimitedDetails}
**Note** I chose "LimitedDetails" because I don't want users seeing everything about meetings in case they might be sensitive like "we're closing down your office". You can set different levels of access, which are listed in this TechNet article.
Now open a Room Calendar in Outlook or OWA, and you should see the Organizer and Room:
Now you'll have happy users!
Wednesday, May 27, 2015
Exchange 2013 Adding Public Folders in OWA
Microsoft has tried to do away with Public Folders (or at least threatened to) numerous times and they keep coming back in new versions of Exchange. The problem with 2013 is that they are not viewable in OWA by default like they were in Exchange 2010.
Now, I do agree Public Folders should go away, but many organizations use them and some (like my current org) use them heavily. That being said, MS shouldn't make it harder to use them, instead of just ditching them...when I say they made it harder, you can only add one Public Folder at a time, and not any top-level ones either.
How To Add Public Folders to OWA
Right-click on Favorites in the left pane, click Add Public Folder.
In the dialog box, select the folder you want to add to Favorites and click the Add button.
**Note** You cannot select the "SUBTREE" and if you select a top level folder, it will only show items in that folder, not the child folders.
So, you have to manually go through and add each and every Public Folder you need...if users need a bunch of folders, they have some busy-work to do!
Now, I do agree Public Folders should go away, but many organizations use them and some (like my current org) use them heavily. That being said, MS shouldn't make it harder to use them, instead of just ditching them...when I say they made it harder, you can only add one Public Folder at a time, and not any top-level ones either.
How To Add Public Folders to OWA
Right-click on Favorites in the left pane, click Add Public Folder.
In the dialog box, select the folder you want to add to Favorites and click the Add button.
**Note** You cannot select the "SUBTREE" and if you select a top level folder, it will only show items in that folder, not the child folders.
So, you have to manually go through and add each and every Public Folder you need...if users need a bunch of folders, they have some busy-work to do!
Thursday, February 19, 2015
Exchange 2010 Shared Mailbox Calendar "Share Calendar" Option Greyed Out
By default, when viewing a Shared Mailbox Calendar in Outlook, the Share Calendar option is greyed out/unavailable. This is by design because users aren't really supposed to share calendars that are already shared. But on occasion, there might be a business need for a user to share that calendar with others.
The workaround is to use OWA to share it out.
There are two ways to go about sharing, and both require Full Access on the Shared Mailbox.
The first option is to open OWA with the shared mailbox address at the end like so:
www.webmail.exchangeitup.com/owa/sharedmailboxcalendar@exchangitup.com
**Note** Change the domain and Shared Mailbox name to match your environment
1. Once you've got the mailbox open, hit Calendar in the lower left pane.
2. With the calendar open, click Share on the top ribbon, then click Share This Calendar in the drop-down.
3. In the new window, pick your contacts you want to share with, set a subject, and pick the Free/Busy options.
4. Send it away.
The second option is to log into OWA as you normally would, and in the upper right corner, click your Name.
In the Select Mailbox field, type the Shared Mailbox name, and hit Open.
Then follow steps 1-4 above.
The workaround is to use OWA to share it out.
There are two ways to go about sharing, and both require Full Access on the Shared Mailbox.
The first option is to open OWA with the shared mailbox address at the end like so:
www.webmail.exchangeitup.com/owa/sharedmailboxcalendar@exchangitup.com
**Note** Change the domain and Shared Mailbox name to match your environment
1. Once you've got the mailbox open, hit Calendar in the lower left pane.
2. With the calendar open, click Share on the top ribbon, then click Share This Calendar in the drop-down.
4. Send it away.
The second option is to log into OWA as you normally would, and in the upper right corner, click your Name.
In the Select Mailbox field, type the Shared Mailbox name, and hit Open.
Then follow steps 1-4 above.
Tuesday, October 15, 2013
Lync IM/OWA Integration with Wildcard Certs
A lot of organizations use wildcard certificates for Exchange and Lync, and although MS doesn't really like wildcards to be used, it's doable. When integrating Lync with OWA, you'll get a "Instant Messaging isn't available right now" message. The workaround is to install local certs for the IIS service on your CAS hubs.
1. Request new certificates using the Web Server Template on each of your CAS hubs from your local CA. Add the Trusted Application FQDN of the CAS hub you are working on, as the Subject Name. You can name them whatever you like. Make note of the thumbprint(s) of the new certs(s).
**Note** If the Web Server Template isn't available, you'll need to allow your Exchange Servers as "Allowed to Enroll" on the Template's Security Tab on your Root CA.
2. Assign the new certificates to IIS and OWA by running:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingCertificateThumbprint <New Certificate Thumbprint>
3. Restart IIS with a iisrest/noforce command
4. Add the CAS hubs to the Trusted Application Pool in Lync Topology Builder
5. Log on to OWA and check that it works
**Note** The new "local" certs you just created and assigned are only for the IM integration, they will have no effect on OWA functionality...OWA will still work as it has been.
1. Request new certificates using the Web Server Template on each of your CAS hubs from your local CA. Add the Trusted Application FQDN of the CAS hub you are working on, as the Subject Name. You can name them whatever you like. Make note of the thumbprint(s) of the new certs(s).
**Note** If the Web Server Template isn't available, you'll need to allow your Exchange Servers as "Allowed to Enroll" on the Template's Security Tab on your Root CA.
2. Assign the new certificates to IIS and OWA by running:
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -InstantMessagingCertificateThumbprint <New Certificate Thumbprint>
3. Restart IIS with a iisrest/noforce command
4. Add the CAS hubs to the Trusted Application Pool in Lync Topology Builder
5. Log on to OWA and check that it works
**Note** The new "local" certs you just created and assigned are only for the IM integration, they will have no effect on OWA functionality...OWA will still work as it has been.



