Exchange online: Conference Room Provisioning changed to AutoAccept

A heads up for admins who plan to provision new resources in Exchange Online: the defaults will change from AutoUpdate to AutoAccept.  This change will occur on November 15, 2018.


What does this mean? It's another 80/20 rule: depends on the type of resources and if you are a new or existing customer.


For existing Office 365 customers:  

• 80%: Most of our clients configure resources (rooms, equipment) as AutoAccept. If the user wants to book a room on a particular date/time, Exchange will book it if it's free. 
• 20%: "Managed" rooms.  Those are the ones only specific users can book, or an admin has to approve. Examples are the Executive conference rooms, HR Interview rooms, the Auditorium, etc.  For those rooms, this will be a problem. 

For new Office 365 / Sumatra's Migration customers,

• NO IMPACT:  For all migration customers, we recommended you set ALL of your rooms to either None or AutoAccept (depending upon the migration tool). You will replace the defaults.

To check:
Get-Mailbox -RecipientTypeDetails @("Equipment","RoomMailbox") -ResultSize unlimited | Get-CalendarProcessing | Format-Table-Property Identity, AutomateProcessing





See the MS announcement here: Exchange Online - calendar AutomateProcessing changes through PowerShell

Travel Time for Outlook -- our first pass -- we want your feedback

We spend a lot of time making calendar data go into Office 365 / Microsoft Exchange.

So when one of us (Russ) needed to do all sorts of travelling for a community project he was on he immediately started wondering:  WHY is there no good way to add travel time to an appointment or meeting in Outlook?

February 2021 We've gotten three requests about this over the last few weeks.  If you're a corporate entity that's interested, drop us a line infoATsumatraDOTCOM.  We're in a soft re-opening of the code.

Of course since he runs the development group at Sumatra he was in a position to do something about it and over the past few months has been engaged in the admirable engineering tradition of skunk works projects.

Truth be told, EVERY project at Sumatra is skunk works, but no matter.

Herewith we invite you to try out our first pass at Travel Time for Outlook.  It's not as full-featured as we envision but it's as functional as other offerings we see people wanting to charge money for.  And we'll let you use this for free.

What this looks like on Office 365:

It's a small icon

Pressing that gives you these options:

Saving it gives you this:

So far pretty simple and we've got our directions for extending it.  But we're listeners.

You'll have to contact us for the URL to install from, but as long as you're willing to provide feedback we're game.

How to install this:

• Sign in to Office 365: https://outlook.office.com/owa/
• Pick the “gear” icon and select Manage Add-ins

• Choose Add-ins, My add-ins, Custom add-ins, Add a custom add-in, Add from URL

• Contact us infoATsumatraDOTCOM for the URL to use.
• Accept the warning, etc.., then close
• Go to your calendar. Create or open an event
• Select the Travel Time icon

Now you get to add travel and/or return time.

There's a lot more work to be done but this is a start and we'd welcome your input on how you're using it.

Make Several Gmail Addresses Out of One

Love this TechTip from the New York Times:

Make Several Gmail Addresses Out of One

Enterprise Exchange / Office 365 Resources: You can manage them better

As an enterprise Exchange / Office 365 administrator you've probably run across some problems that drive you bug-house: security, backup, compliance, forensics, response time, .... the list drones on like a "Wonderwall" knock-off.

But one thing we can help you with is RESOURCES.  There are a series of things you can do to make your resource management smoother from an end-user experience in Exchange.  AND you can do them server-side.

The resources we're talking about here are the resources in a calendaring sense: Rooms and objects/services that are scheduled with meetings.  (I mean, you KNOW this is what the whole blog is about, right?)

A (few) word(s) of warning on prerequisites here:  it helps to have experience with PowerShell and Permissions.  You are definitely going to need experience setting permissions for resources in Exchange. 

We've blogged on all of this before, but this is the first time we've put it all together in one convenient post.

Let us begin.

Have you really thought through Delegate Access?

You may be using Delegate in the less effective way.  In general you should use booking delegation instead of classic delegation.

See: Two ways to grant access to a Resource in #MSFTExchange

Explanation:  Booking delegation makes it easier to access the resource should you need to (since classic delegation resources are disabled accounts by default) and you do not have issues with server vs. client-side rules and priorities.  

This does mean having resource delegation managed by the administrator.  As we proceed you'll increasingly see how this saves you hassle later on.

Do you ever have two meeting groups showing up for the same room?

You have had a double booking issue and didn't think you could do anything about it.

We KNOW you do because Double-Booked Meeting Rooms in Office 365 (and how to avoid them) is one of our most popular posts EVER!

But you can

If you just want to see how big an issue you have, use our reporting tool:
See: Callable PowerShell script to report on double booked resources in Exchange 2016 / Office 365
it's a PowerShell script that will tell you which resources have double-bookings.


If you want to proactively manage the issue on an on-going basis -- check out our solution to the problem:

Three Basic Ways of Dealing with Double-Booked Resources in the Sumatra cmdlet

Zimbra to Exchange / Office 365 Calendar, Contacts, Tasks migration again field-proven

Once again we've migrated a domain from Zimbra to Exchange 2016 -- calendars, contacts, and tasks.  They also followed our guide to Zimbra email migration with imapsync.

This in itself is not noteworthy.

What was different about this was it was a municipality running at small scale (100 accounts) and they took the lead on running the migration themselves with little input from us. So they could keep their costs down while still getting a high quality calendar migration.

To quote them:

The migration went off without a hitch – no complaints that I have heard about missing items.  Thanks so much for the helpful tool!

Huzzah!

The system works!

New Zimbra Authentication Options in Office 365 Calendar Migration

Zimbra on-premise migration customers have typically kept their legacy directory services until they went live in production. 

When customers migrated from hosted Zimbra, they ran a hybrid deployment (i.e. ran directory services in parallel with Office 365.)  

Typically, both legacy and target servers were in the same domains. That is, until we received a request from a client who wanted to migrate from Zimbra to Office 365 AND change the domain name.  

In zCalReader 6.2.03 and above they can.

A pull-down on the configuration screen will let you choose your URL format based on your authentication scheme. 

Note: You should still use your Zimbra Admin credentials for the Zimbra side.

False positives in antivirus software

So last week we had a low-level inquiry from a company wanting to migrate MDaemon calendars to Office 365.

They'd already tried the arduous PST method and found it wanting.

So we set them up with a trial version of the migration software.  Next thing we heard from them was that TrendMicro AV was flagging it as containing ransomware.

Seriously?

Like, how realistic is it for us to send out ransomware when we maintain a blog going back to 2005 (you're on it), a public web site, a Twitter account, and we give you our direct email addresses?

A quick search in the spirit of JFGI for "false positives antivirus" gives some insight.

So this is not just something that is affecting us.

We can understand your caution.  We in fact encourage your skepticism and welcome your desire to challenge us.  Anyone who's been through our various doc sets for migrations knows that we promote planning and preparation.

Since our code works on Exchange / Office 365 servers it is by definition server-modifying, so I can understand how detection algorithms could get wary.

Keep in mind, though that Sumatra Development is one of the few companies you deal with where if you're not talking to the people who wrote your migration code you're only one degree of separation away from the person who did.

A migration WE were put through......

This is a bit of a departure for us.

Most of the time when we write about migrations it is us at Sumatra enabling a migration from a legacy calendar server into Microsoft Exchange for someone else.

Recently though WE were the recipients of a migration.  In this case of our web site and associated on-line presence from one hosting company to another.  

Initially this was not our choice as IX Webhosting got bought by Site5.

We had a completely miserable experience! We want to share the points of failure.  Doing our own migrations since 2001 (really?  It's been that long?) we've battle-hardened our own processes and documentation to deal with all of these issues -- but the fact it happens in a scenario that was much simpler than a full-state calendar server migration shows how easy  it can be to slide into the Upside Down.  We'll first talk about the timeline, then the lessons learned.

Timeline  If you want to see a rough timeline as it played out in Twitter -- check out our feed.

This email was our first warning this was happening:

Note the up-beat tone, the promise that all of our content should be there for us, and the lack of any warning to back-up or how to escalate if/when things go wrong

Yeah....  already the Spider-sense was tingling.

But I figured I'd get another communication telling me WHEN they were transferring our site since that's kind of a big deal.

Nope.

"Ruh Roh Raggy!"

Our first indication was when our email, site, and FTP access went down on Tuesday April 17, a week after this missive.


We were able to get email up pretty quickly thanks to our knowledge that the MX records and DNS servers needed updating, and we were almost... kinda... (*sort of...*)  not not really anywhere near getting our web site running again.  We just ignored other things like FTP by this point.  

To be fair our data and settings DID stay the same (as promised) -- they just weren't set in any of their systems properly.  I'm sure years of weasel-like business practices went into that intro letter without considering the customer impact.

We waited three business days for them to resolve the problems.  But by Friday morning when they misconfigured our SSL certificate, causing visitors our site to be redirected to a site in Peru, we pulled the rip cord, fired Site5 and went with TMD Hosting who got us up and running in really good time.

How bad was Site5?  Seven days after we'd severed relations with them, gotten our site up and running on TMD, and propagated our new DNS, Site5 support contacted us to tell us they were still working on the problem.  Yeah, guys, you keep us in that loop!

Lessons Learned (from what went wrong):

• There was no honest communication from the get-go -- and I mean zero.
• There was no public time-line
• There was no back-out plan
• There was no opportunity to test.
• There was no parallel hardware available (literally copy data to new machine then decommission the off old machine)
• There was no ability for quick response and communication

Happy to say that this debacle did not affect the main migration going on at the time.  Why? Because we're big in up-front communication, warn people that things can (and do) go wrong, create a plan that deals with things when they do.

Latest version of imapsync includes web interface!

Woo hoo!

The latest version of imapsync includes a web interface:

Try it out at  https://imapsync.lamiral.info/X/

Sumatra web site again up and running

Thanks to the good and capable folks at TMDHosting (whom we recommend) Sumatra's web site and email are once again running.

We recommend TMD.  They came up aces for us when we needed 'em.

Sumatra migrating main site to a new hosting company

Folks,  we gave up on the company that rendered our previous hosting company into bacon grease.  Working with a new vendor to get up and running again.  Those of you currently working on a calendar migration / calendar project with us know how to get in touch with us.

Problems on our web site as our hosting company is acquired

Folks,

Our web hosting company is being acquired by Site5, who has thus far proven to be REALLY MISERABLE. 

So if you get annoying messages from trying to access our web site or FTP please give it a 24 to 48 hours as the new DNS records replicate through the net.  (Am I angry that these Site5 guys just bought out a bunch of customers and their first act of customer service is to shut us down and not even bother to warn us ahead of time?  Yes.  Yes I am!)

If things are not up at a decent pace we'll let you know here.

Twenty minutes into my turn in the support queue:

For April Fool's Day: Soul-Crushing Meetings

We in Sumatra migrate meeting data.
We cannot however make your meetings any less soul-crushing.

I'd love to give credit to the originator of this if they tell us who they are (came to me by way of my cousin who got it from his feed who posted it from some other feed and yadda yadda yadda).

DAVical and Open Source Calendar Migration to Exchange / Office 365

We got an inquiry a while back about migrating DAVical to Exchange.

They vanished as happens in the way of people with more ambition than budget, but it did get us thinking about how to do Open Source calendar server migration to Exchange or Office 365.

This is made easier because we already have a full-state migration method out of Zimbra into Exchange and Office 365.

Works like this:

Short answer is I'm pretty sure we can do it using the REST implementation we already implemented for Zimbra.

In Zimbra the format to download an ICS to our migration is:

http://SERVER/home/username/calendar?fmt=ics

In DAVical (https://www.davical.org/clients.php) it's

http://SERVER/caldav.php/username/calendar/

The ICS is close enough that it presents no problems, and there is admin access to all accounts.

So we have a decent chance of getting this to work.

Also Zyg's tried it out in the lab and got it to function, but undoubtedly there's a bug or two in there that real-world hardening will discover and squash.

So sites with several hundred users and a willingness to spend part of their test phase in careful mode can feel free to contact us.

DAVical is built on top of PostgreSQL which we read in order to migrate Apple's iCalendar server, but there's no indication that's a superior migration path.  And it represents a little more work so -- nope.

Security best practices for Office 365

I went to a local Microsoft presentation that was supposed to be a "Deep Dive into Office 365 Security."

Word of warning: Very rarely is any Microsoft presentation a deep dive.

This one was no exception as the presenter spent way too long talking about weak passwords and putting up vague slides that were really good at telling you what your problems can be but way too vague on how to specifically, actually solve them.

Still this Microsoft shill was up-front that the slide contents came from this posting:

Security best practices for Office 365 

Not a bad summary of issues you need to face as you move to Office 365.

The links include how to activate specific security safeguards in your Office 365 environment.

Now: It seems to me that since this environment is completely in the hands of Microsoft, which as a company should be really concerned about client security, perhaps a decent subset of these should be turned ON by default with instructions on how to turn them off, instead of OFF by default with instructions about how to make your Office 365 experience more secure.

But that's just me wondering WTF?!?

New in Office 365: PowerShell and Delegate Permissions

If you've seen our earlier post Migrating Delegate Permissions: The 80/18/2 Rule, you know that in on-premises Exchange at least you can use the Add-MailboxFolderPermission cmdlet in PowerShell to set Delegate Access.

Now Microsoft is allowing you to use this capability on Office 365.

Sidebar: Is anyone else getting tired of discovering which cmdlets work in on-prem Exchange but not in Office 365 by Microsoft's tried-and-true method of "well, walk into the minefield and if you do not explode you'll be fine?"

Log into your Admin account and you should be able to see this update:

This lets you use effective scripting and server-side methods to handle Delegates.

As we always counsel: Be really careful how you set up Delegates in Exchange / Office 365.  See our article:  Two Ways to Grant Access to a Resource in MSFT Exchange. and use the "Booking" Delegation approach.

Sometimes Low-Tech is the Best Tech -- even in calendaring

The New York Times recently did an article "In an Era of 'Smart' Things, Sometimes Dumb Stuff is Better."

You may be surprised that for some people who spend almost all their professional time in Microsoft Exchange and Outlook and breaking legacy calendaring systems (not that there are really any left for us to break), Zyg and Russ are calendar Luddites.

If you've seen us come into a customer site you may have been astounded that the calendaring guys pulled out paper organizers.

Zyg is big on his medium-form filofax and Russ still uses the Time/system book he was trained on at Lotus.

WHY? you are probably asking.

Really simple:  every server, client, and data set at Sumatra is fair game to become an immediate test system by any employee should the need arise.  And yes, it's happened to each of us and we're kind of happy when it does because it means we're shagging down issues making our latest generation of calendar migration tech better.

Now we still have our laptops with Outlook clients.  Truth be told I've tried every organizer / email client since Lotus Agenda.  I do not love Outlook (there is a lot to be unhappy about) but find Outlook just keeps evolving and no other client-based organizer can lay claim to that.

We also both have analog wristwatches.

Migrating Delegate Permissions: The 80/18/2 Rule

From the Oracle Communication User Documentation,

https://docs.oracle.com/cd/E56607_01/doc.301/e73472/olh_calendar001.htm#CONOH202

calendars have the following delegate options:

Exchange has the following delegate options.

You should now see the problem about how you move from legacy to target and keep everyone happy.

Basically, you cannot possibly keep everyone happy if you try to migrate delegate permissions from Oracle to Exchange.  The only sane solution is to let users set delegates themselves post-migration.

While it is possible to set Delegates via PowerShell in Exchange via Add-MailboxFolderPermission, Sumatra does not recommend migrating legacy delegate lists.

1. The access model between legacy and target system are different enough that any mapping is a “best guess.”  While this is fine for many users, it will lead to dissatisfaction among an undetermined subset.  And long experience with migrations has shown us that user communities are happier with a migration with clear rules and expectations universally applied.
2. Migrating delegates automatically propagates a situation of “maximum access.”  Now is a perfect time for end users to review who has access to their calendars and re-think it.
3. Use it as a primary incentive to get users training on the new system.

Exception to the rule:  Zimbra to Microsoft Exchange.

Since Zimbra consciously decided to rip-off emulate as much Microsoft functionality as explicitly and exactly as it could, you have a higher chance of success here.  But please see comment #2 above about propagating a culture of "maximum access."

Using PowerShell to SET permissions in Exchange is straight-forward.

BEWARE:
Migrating Zimbra permissions to Exchange does not automatically set up menus for user access via Outlook or OWA!

You will likely perpetuate security issues for users who have changed roles and should no longer have access to some accounts! Your migration is the best time to review all of these!

To extract Zimbra delegate permissions:

Zmmailbox will give permissions for any mailbox or calendar you want as follows

./zmmailbox -z -m jimi@sumatra.local gfg /Inbox
./zmmailbox -z -m jimi@sumatra.local gfg /Calendar

This also works for tasks and contacts.

To save to a text file append '> permissions.txt'

See: https://wiki.zimbra.com/wiki/Ajcody-User-Management-Topics

Permissions exist as per the following table:
 r = read
 w = write
 i = insert
 d = delete
 x = accept/decline invitations
 a = administer

To insert Zimbra permissions into Exchange:

Use:

Add-MailboxPermission in PowerShell

Add-MailboxFolderPermission -Identity jimi@sumatra.local -User zyg@sumatra.local -AccessRights Editor


This will give Zyg editor delegate access to Jimi's mailbox.

And of course, you will need to manipulate or edit the text file you originally extracted from Zimbra.  But this is not beyond high school programming or scripting, people.

You can also delegate other folders like jimi@sumatra.local:\Calendar and so forth.

See also: How to use Powershell to set delegate for user mailbox in Exchange 2010 and Office 365

Again, just because you can migrate permissions does not mean you should.

Seriously talk this over.

Migration: Email Distribution Groups and the 80/18/2 Rule

Distribution groups are not as much a pain in some cases as you might imagine!

Keep in mind these are an email migration issue as opposed to a calendar migration issue -- but we're interested in writing about stuff to solve problems, not pass blame.

For MDaemon to Exchange public distribution lists we needed to write our own specific application.   Our specific application did the mapping from legacy domain to target domain and also used our own mapping files for user/resource IDs, so .... it really kicks butt.

Nobody else we know does this.

And in general for legacy systems it may not be possible to even generate the information you need in order to make this work.  As usual we're talking server-side solutions for the entire enterprise as opposed to lame client-side solutions for one freaking user at a time.

But we'll tell you how to do this if you have the chance.

Again we begin with the end business goal of migrating into Exchange or its cloud sibling clearly in mind.

Refer to: Distribution groups and EWS in Exchange   and use New-DistributionGroup.

From Zimbra it's not too bad.

In Zimbra getting this information for public groups is actually very straightforward.  See Zimbra.List all existing distribution list and the respective members

This command:

zmprov gadl -v > dist_list.txt

will list all distribution lists with their members and output it to a text file.

The same command with some variations:

for i in `zmprov gadl` ; 
   do zmprov gdl $i zimbraMailAlias zimbraMailForwardingAddress ; 
   done > /tmp/dist_list.txt

accomplishes the same thing

Now -- keep in mind, if in going into Exchange you are changing any user IDs or your domain you're going to need to do some work on the export file before you start using EWS to re-create the lists.

To export single distribution lists in Zimbra (see: https://forums.zimbra.org/viewtopic.php?t=48514)

zmprov gdl dist_list@domain.com > dist_list.txt

To create a distribution list (what Exchange refers to as a distribution group) in on-premises Exchange 2013 use

New-DistributionGroup -Name (+Additional parameters as necessary)

See: https://technet.microsoft.com/en-us/library/aa998856(v=exchg.150).aspx

To create a distribution list in Office 365 / Exchange 2016

New-DistributionGroup -Name "RockIcons" -Members jimi@sumatra.com,janis@sumatra.com,jerry@sumatra.com,puffy.amiumi@sumatra.com

See: https://technet.microsoft.com/en-us/library/aa998856(v=exchg.160).aspx#Syntax

Dynamic Distribution Groups

And for some business purposes you want to consider Dynamic Distribution groups.  You may also know these by their former name of Query-Based Groups.

These come to the fore when you have a (wait for it....) very dynamic membership in the sense of people changing roles or having a high turnover.  Example:   A project group or a support desk.

Check over Dynamic Office 365 Groups might come with a big cost for a good analysis of the pros and cons.