Sunday, December 22, 2013
Their statistics on email dissatisfaction are interesting if not completely compelling. In general we've had little experience of users at the enterprise level who are really happy with Google as an enterprise solution.
As nearly as we can tell the migration Microsoft offers is exclusively email.
If there's any corporate interest in a full-state calendar migration from Google to Exchange -- let us know. One of the only reasons we did a migration INTO Google was with the expectation we'd have bigger opportunities getting people OUT of Google and into Exchange.
Tuesday, December 17, 2013
The words send shivers down my spine.
We got our first request for a tool to insert holidays server-side after we did a migration for the folks at HMS (shout out to you guys!) for Exchange 2003. That was CDO-based tech, with its positives and negatives.
After Exchange 2007 came out we re-wrote the tool for Exchange Web Services (EWS), added a variety of features and found that folks really wanted it, but not at enterprise licensing levels. Go figure.
But it's a good way of showing what we can do with calendars in migrations, so we've produced an open-sourced lite version of a holiday cmdlet.
Sample code where we build the holiday looks like this:
We've also hard-coded a few things (like, it's picking up your credentials to authenticate against Exchange, so you ARE the service account!).
We think of this more as a mini-tutorial on how to do a calendar-centric cmdlet.
Why a lite version and not the full thing?
Mainly because the full version has a lot of expertise behind it that we're reticent to just give to those of you toiling out there on software knock-offs.
Where from here?
We are market-driven. We're keeping an eye on what we hear back.
Monday, December 16, 2013
I was very pissed that Outlook 2013 RTM no longer showed "future" appointments in the ToDo bar. I was thrilled to learn it's available -- see Microsoft's KB# 2837618.
And now for the really good news: The patch causes Outlook 2013's IMAP folders to fail to synchronize. I'm thrilled to see my appointments 7 days out, but even more pissed that I can't get new mail sent to my inbox, or preventing me from setting up OOF messages.
InfoWorld said it better than I could in a recent article: Botched Outlook 2013 patches KB 2837618 and KB 2837643 break Out Of Office reply, Free/Busy, and more. InfoWorld found a detailed synopsis of the issue, written by Matthew Stublefield from Missouri State University.
Bottom line: DO NOT apply this patch until Microsoft figures out how to fix the fiasco.
Friday, December 06, 2013
If your passwords in Beehive / Oracle have expired, then Oracle Unexpire and Unlock Accounts is really, really useful.
So too is Oracle Database Security Checklist.
Thursday, December 05, 2013
But Microsoft's Blog Entry from their General Counsel is that kind of amazing just because I find myself in the rare position of applauding Redmond for taking some stand for user privacy against the knee-jerk, butt-covering, bureaucrats who think Orwell proposed a really great idea.
Keep it up, guys!
Yes, this is one of our rare posts that has nothing to do with calendaring but it is so momentous I need to get on record as supporting it.
Tuesday, December 03, 2013
Monday, December 02, 2013
In similar words from Hamlet: methinks they doth protest too much.
Here it is with brief commentary on BerryReview.
Maybe BlackBerry is not living under a rock for acknowledging they are under siege, but they do not acknowledge that this is not in the same envionment as before. Like Thursday's Macy's Parade the balloons have collapsed and the parade has gone by. Rather than a leader of the smartphone marathon BlackBerry is now in a dash to safeguard its highest hanging fruit while the lowest hanging drops in other baskets.
We've had our love/hate affair with the BES server over the years. As both BES and our migration technology for E2K3 were CDO applications anything that screwed up BES (usually permissions or CDO calendaring bugs) were harbingers for what was going to happen with our code. To this day some of our all-time most popular blog posts are referenced on the BlackBerry forum to deal with permissions issues.
I wish them good fortune.
But I also wish you the same thing we advise everyone: look at all your options and test the snot out of them with the knowledge that your user base is seeking direction from you now and your next performance review is coming faster than you think.
Thursday, November 21, 2013
So if you did not know it before, there's a hard limit of 25,000 meetings in Oracle Beehive Extensions for Outlook. Hard as it is to believe we do know of users who have exceeded this in other legacy systems.
Tuesday, November 19, 2013
We do not make them live in migrations. The reason is simple: they confuse the heck out of the attendees and it's not worth it. While you can communicate to your internal folks that a migration is going on and we are taking care of re-creating the meetings, we cannot reach out of your organization and re-accept or decline for your external guests.
But we can let YOU know about them.
So as of all forthcoming version of our process we're keeping the record of external guests in the meeting agenda, exactly as you see here post-migration.
Monday, November 18, 2013
An 850 user Beehive to Exchange Migration validated fine (notable for two things: First European Beehive migration and first multiple instance Beehive migration) and then while in migration started throwing impersonate errors for what became a total of ten users.
Now ten out of 850 is about 1% -- which to us is still too great an error rate for us to tolerate.
But it seemed really wasteful to undo the entire migration for ten users.
Here's what we did.
We modified the insertion to allow for a single user. Not via validation of that user which is a good test procedure but it would be insufficient here. You need the validation file to be as entire as you can get it -- otherwise there will be inaccuracies.
First fix your permissions issues with those users.
THE ABSOLUTELY SAFEST WAY
- Create a new sub directory for each of the accounts. Remember to copy configuration and the two account validation and mapping files
- Launch the bcalreader UI, and set the lower and upper limit for the first account’s SMTP address root, e.g.: “jimi.hendrix” to “jimi.hendrix”
- If there are multiple accounts that have this root, follow the limit values with an “@” sign. For example, if you have two accounts “jimi.hendrix”, “jimi.hendrix2”, and you only want to process “jimi.hendrix”, set the limits: “jimi.hendrix@” TO “jimi.hendrix@” Otherwise the tool will migrate “jimi.hendrix” and “jimi.hendrix2”, and you will end up with duplicates in the “jimi.hendrix2”’s mailbox.
- Validate, then press the “process all” button.
- Repeat for other users
- This inserts all meetings/contacts/tasks owned by the user, and process all invitations received from other users.
- However, it will NOT process invitations sent from this account to other accounts. Those invitations will remain in his invitee’s in-boxes. We suggest you leave it that way.
- Communicate to your end users that the migration may have left some meeting invitations in their inbox. Suggest they process those invites the way they did in Beehive (e.g., if they accepted the invite in Beehive, accept the one in Outlook; If they declined the invite in Beehive, decline it in Outlook.
The best way in this case means getting the outcome you could have had if the impersonate had not failed. But it is a little more intricate and has the possibility you press the wrong buttons.
Do this in the cold light of morning. It is way too easy to hit the wrong button when you are sleep deprived and stressed.
- Create a sub-directory that you will use to process the accounts that had impersonation problems.
- Copy bCalReader v2.0.11 or greater and the validation file.
- Change the limit to the account. Put an “@” after the SMTP address, e.g.: “Jimi.Hendrix@”
- Press “Process All”.
- Repeat for the remaining accounts.
- Check the “show individual steps”, and re-process the invitations as follows
- Press the “Respond to Invitations” button on each instance. When they are all done,
- Press the “Apply response Exceptions” button on each instance. When they are all done,
- Press the “Update Tracking Info” button on each instance. When they are all done,
- Press the “Final Cleanup” button on each instance.
- When they are all done, you are finished!
Thursday, November 07, 2013
Since re-creating calendar state in Exchange requires sending, responding, and creating exceptions for meeting invitations, this technique does require some special handling, which we're detailing here.
First, the screen morphs a little:
- Go to each computer you want to use
- Install bCalReader and its associated .DLLs
- Validate and map all your users on one machine and then COPY the account_validation.txt and alt_account_maps.txt to the other instances.
Wednesday, November 06, 2013
A little bit of background is due here. We use the rate of 850 objects per minute as a rough gauge of Insertion time into Exchange in our Meeting Maker or OCS migrations. But that is ONLY for insertion into Exchange from our own data structures and does not include the time for any processing of Legacy calendar data (the Extraction phase).
For Beehive, we've combined the EXTRACTION and INSERTION into one application where we read directly from Oracle's relational database.
And needless to say performance varies hugely with the Beehive topology and servers.
So a few general results:
- Your migration performance improves 20-30% if you SHUT DOWN Beehive (technically our results were 18% to 33%, in a variety of configurations, but rounding makes them easier to wield).
- Going into on-premises Exchange yields more reliable performance than insertion into Office 365.
- Extraction involves a certain amount of overhead that is difficult to remove and highly dependent on Beehive system and configuration. Think of it this way: it always takes a certain amount of time to pull up a user.
- Given that, look at your summary report for you top users and use that data in conjunction with your test experience to gauge your insertion times. If you need help analyzing this contact us.
- Calendars with more objects take longer to insert so only take data as far back as you need. If we see serious requirements for lots of past data we'll modify the code to allow you to insert current data as quickly as possible (so you are functional) and then go back and insert your historical archive. This has been a regular feature of our other migrations for a while now, but Beehive migrations are relatively new.
Saturday, September 21, 2013
Tuesday, September 10, 2013
It works with Exchange 2007, 2010, and 2013, as well as Office 365.
You will have to set permissions to be able to access calendars.
You can download it here.
Update December 10, 2013: Link removed while we consider alternates for the holiday cmdlet.
Update December 17, 2013: We created an open-source cmdlet project on CodePlex.
Tuesday, July 30, 2013
New-ThrottlingPolicy SuThrottlingPolicy -EWSMaxConcurrency $null -EWSMaxSubscriptions $null
Set-ThrottlingPolicyAssociation -Identity exsu -ThrottlingPolicy SuThrottlingPolicy
For the inquiring minds, the following are set in Exchange 2010, but NOT used in Exchange 2013:
|Error||Throttling policy parameter||Description|
|ErrorExceededConnectionCount||EWSMaxConcurrency||Indicates that there are more concurrent requests against the server than are allowed by a user's policy.|
|ErrorExceededSubscriptionCount||EWSMaxSubscriptions||Indicates that a user's throttling policy maximum subscription count has been exceeded.|
|ErrorExceededFindCountLimit||EWSFindCountLimit||Indicates that a search operation call has exceeded the total number of items that can be returned.|
|Occurs when the server is busy. The BackOffMilliseconds value returned with ErrorServerBusy errors indicates to the client the amount of time it should wait until it should resubmit the request that caused the response that returned this error code.|
Or, the HTTP status codes that are returned by throttling errors:
|HTTP status code||Description|
|HTTP 503||Indicates that EWS requests are queuing with IIS. The client should delay sending additional requests until a later time.|
|HTTP 500||Indicates an internal server error with the ErrorServerBusy error code. This indicates that the client should delay sending additional requests until a later time. The response may contain a back off hint called BackOffMilliseconds. If present, the value of BackOffMilliseconds should be used as the duration until the client resubmits a request.|
|HTTP 200||Contains an EWS schema-based error response with an ErrorInternalServerError error code. An inner ErrorServerBusy error code may be present. This indicates that the client should delay sending additional requests until a later time.|
Tuesday, July 23, 2013
We want to draw the distinction between time management (something individuals either do or not do for their personal schedules) and calendar metrics (something you can read from the aggregated calendar data in your Microsoft Exchange server).
Here we'll start taking a look at some of the global reports you can extract that enable some insight on what your corporation is doing.
Some data we extracted a while ago generated the following results:
Not surprising (to anybody who's worked in an organization with more than fifty people) the number of meetings drops at lunchtime. We interpret this as people wanting to get some private time, but any anthropologist out there will ask how we normalized our results, set up proper controls, and did double-blind studies. None of us are anthropologists. What is more interesting to you the manager are the twin peaks of mid-morning and mid-afternoon for the most popular meeting time. Plan your resource use accordingly.
The outlying time of midnight - 1 AM we think was either security or manufacturing.
Which hour do people meet leads to the question which DAY is favored. In the above report we found that meeting frequency peaks on Tuesday. In LOTS of both legacy and Exchange data we have seen Wednesday and Thursday being the peak, but almost never Monday or Friday.
Tuesday, July 16, 2013
Jeff Weiner (CEO LinkedIn) notes his managers complain about managing their inbox and their meeting schedules in his post: A Simple Rule to Eliminate Useless Meetings, and The Importance of Scheduling Nothing.
Rajat Taneja (CTO, Electronic Arts) wants to Cut Down on Unnecessary Meetings.
I found Rajat Taneja's post most interesting. He talks about understanding "how we spend our time," and then he tracked how he spent his time. We think the act of measurement is a critical component that will drive the CEO to force the organization to change the meeting behavior.
Both of these are geared towards the meeting organizer, that is, changing individual behavior. But both of these being high level executives, the more interesting question they do NOT pose is: can we get a handle on how the enterprise is spending its time? Are we being efficient or not? And can we read this out of Microsoft Exchange?
Having been looking at scheduling metrics off and on over the years we've been trying to figure out how to interrogate the Exchange server to derive useful metrics on this for analysis on the organization / enterprise level.
It's easy to use server-side tools to get a handle and do reports on how much email traffic is generated and disk space is in use. Email analysis has relatively little dependence or significance on job title or function.
But calendars are precisely the opposite!
As a Tech CEO you usually want your engineering staff working on engineering problems and not in any more meetings than they need to be. But your sales people need to be meeting with clients or they're not doing their job. In between there's a wide gulf as much dependent on individual corporate culture and goals as on anything taught in a management course at Business School.
We took a cut at that measurement, in our recent Oracle Beehive migration tool. See"The Oracle Beehive Calendar Metrics"
post for a screen shot of the metrics. Those of you who have been through migrations with us have seen similar reports on your legacy data.
And this actually is where we made what we think of as our first big break through: that the inanimate objects in the corporation have a lot more importance than you would first think.
In fact -- since the only major issue with them is "how much are they in use?" it's relatively straight-forward to do reporting on them and we've already sliced that a few different ways for people.
We'll show sample reports in a follow-on post.
Friday, July 05, 2013
Tuesday, June 18, 2013
If you want to try this in your environment contact us info AT sumatra DOTCOM and please tell us how you will give us helpful feedback.
Tuesday, June 11, 2013
Tuesday, June 04, 2013
Thursday, May 30, 2013
Now this is not scientific, and it is not necessarily significant. Tips 'n Tricks and Troubleshooting could be calendar-specific at times and not be cross-classified. And E-Mail does not get a separate specific mention, which would provide the most direct comparison.
All we're measuring is the relative time it's tagged vis-a-vis the other tags. Could be it's not mentioned because it's stable and not a problem (we find a lot of problems here, but that's out specialty), or it could be that other priorities are higher.
Thursday, May 16, 2013
We do not even bother looking at calendar migrations INTO Google anymore (the sites we found that were considering Google were really light on any kind of enterprise expertise in the first place).
Our prediction: we will soon be seeing people looking for full-state calendar migrations OUT of Google and into Exchange.
Monday, April 29, 2013
Now you can take categories along.
But there's a little subtlety involved.
Let's look at our favorite test user Jimi Hendrix in Beehive (via the Outlook client): With appointments on International Worker's Day with categories assigned.
Nothing out of the ordinary here.
Now let's run our process and migrate Jimi to Office 365.
Here are the results of the migration into his specific account.
Note that the "Red," "Orange," and "Yellow" categories come over, are retained, and the color pops up as we would expect.
But categories "Migration," "Microsoft," and "Travel" are uncolored, while category "Hayley" HAS a color associated with it. What goes?
The answer is of course: User Configuration. Since on the Office 365 side we used an off-the-shelf configuration, the defaults common to both Oracle and Microsoft came in and displayed. Custom categories need to be created user-side in the defaults (which is a one-time action). Once you assign a color to a category (as we did with category "Hayley" below, it's propagated to all calendar objects with the same category.
Thursday, April 25, 2013
And it just keeps coming.
A company from the Indian subcontinent and another company from the former Soviet Union both contacted us within days of each other looking to acquire our Oracle Beehive to Exchange calendar migration technology. I'll let you guess which one started with "Please send us all your source code....." The other one was a slightly more realistic.
Anyone else pick up a disturbance in the noosphere?
The fact that there were two makes me wonder that is going on here. We are open to licensing this to someone else but as it needs to be a serious inquiry.
Monday, April 22, 2013
We did this preliminary video on how our Beehive calendaring / contacts / task migration into Exchange / Office 365 works.
Look at it on full screen so you can catch all the details.
Updated July 18, 2013 to point to the final video.
Friday, April 19, 2013
Tuesday, April 16, 2013
Post-migration we have all of her email with attachments (including her meeting invitations).
But these meeting invitations are still tagged with Janis's old address:
Saturday, April 13, 2013
We're going to show you how.
IF you are confident with accessing your IMAP set up, you (*should*) be able ignore this step with Test-MigrationServerAvailability. Sashay over to Migrate E-Mail from an IMAP Server to Cloud-based Mailboxes,
You really need to get to the point where you run Test-MigrationServerAvailability:
Test-MigrationServerAvailability -IMAP -YourIMAPServer
-Port (143 or 993)
To do this you need to execute PowerShell (do this as an Administrator) and re-direct your session to the Exchange Cloud. You need to execute these commands in PowerShell, filling in Administrator credentials (call 'em the SuperUser, the Big Kahuna, whatever you want, but you need the rights to administer your entire Cloud account)These commands in PowerShell will do it.
When all goes well it will look like this:$LiveCred = Get-Credential$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $LiveCred -Authentication Basic -AllowRedirectionImport-PSSession $Session
Note that it did not work for me the first time through the lengthy command but it did immediately after with another simple try. Go figure.
When in doubt refer to one of the most useful short webpages you will ever find: Connect Windows PowerShell to the Service.
Now you are in a position to run Test-MigrationServerAvailability.
I have done this here. Note that I was having trouble resolving my FQDN, but just used a the 127.0.0.1 localhost address and was in with no problems. This is not something that will work for you in a real world migration, but I wanted to illustrate it here and did not feel like making my test system available to the wider internet,
If you have reached this point you are knocking on the door to success.
Again, since as nearly as I can tell this is exclusively to test if you can get access to your IMAP server, and the real work of the migration gets done below, you can in all likelihood skip this step. Please feel free to drop some comments if you discover something to the contrary.
A final word: ALWAYS Clean up your PowerShell session by ending with Remove-PSSession $Session.
NOW YOU ARE IN A POSITION TO REALLY BEGIN MIGRATING BEEHIVE EMAIL TO EXCHANGE,
If you successfully complete the instructions in Step 3 you will see this:
Click New and select "IMAP" Not a lot of choice in this if you're coming out of Beehive.
And then start your migration.
Now it's passed into the hands of a greater power than any of us has ever known -- Microsoft's data center.
May they have mercy on your data.
Read the logs and check over any errors. In practice I'd really try to end the process here and not keep a periodic synch running -- that's just asking for trouble. But your circumstances will vary.
And of course I cannot resist saying that while http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff683630.aspx tells you you cannot take calendar and contact information:
Tuesday, April 02, 2013
We built this into SuUNDO, one of our flexible utilities for modifying Exchange calendars (usually to clear stuff out).
You're going to need to do be issuing commands from PowerShell. There is of course installation and configuration, which in the interests of brevity we cut out here. The great thing about PowerShell is its scripting flexibility.
Let's take a look at a sample Lync meeting in Office 365.
If we just wanted to find out how many current meetings are in Zyg's calendar we could just do this:
get-StringsinNotes @LyncCmds -NewPrimarySMTPAddress: "firstname.lastname@example.org"
Output to the screen generates this (telling us this user has one current Lync meeting)
This is recorded in a log file as well.
So far so good -- this can tell us the extent of the number of online meetings that would need to change for all users.
Now, let's take the next step and update them.
Let's say this was an on-premises Exchange installation (it's not, but one of the Cloud's best attributes is as a test system) and we needed to modify just the domain names for these users, from "lync.com" to "sumatra.onmicrosoft.com"
This command will do it:
set-StringsinNotes @LyncCmds -NewPrimarySMTPAddress: "email@example.com" -OldPrimarySMTPAddress: "firstname.lastname@example.org" -OldSIPAddress: "lync.com" -NewSIPAddress: "sumatra.onmicrosoft.com"
And we see the results in the original calendar here:
And now for the magic part, it has been automatically updated in the ATTENDEES' calendars as well!
Of course, you could also use this for updating when users change SMTP addresses only (or both together!),
Tuesday, March 26, 2013
We chose a different path on this new code. Instead of going through an intermediary "extraction" step we read directly from the Beehive Database and insert from there into Exchange 2010.
We still allow for individual mappings (so if Hillary Rodham in Beehive needs to become Hillary Clinton in Exchange we can handle that, or if you want to take this opportunity to recast your Conference Room nomenclature that is completely possible).
Of course, this is a FULL STATE migration so we preserve all of the recurrence patterns (and in this case we can preserve ALL of them), the Guest Lists, and the guest responses. In short: meetings are completely "live" after migrating with this code. It is like your users were on Exchange all along.
Just so you folks can get a glimpse of it:
And since one of Zyg's personal hot buttons is making sure international characters come out correctly, this hybrid German-Spanish text in Outlook on Beehive:
We're still working on some performance tuning -- but you can get a good idea of where this is all heading.
We're also considering migrating all the user preferences and email if we get strong enough demand.
Saturday, March 16, 2013
This is the latest battle story of WHY.
Last night as we were running a migration we started noticing that invitations were not being sent for migrated meetings. Appointments and regular email seemed to be going in fine.
This in our world is a first-rate fuster-cluck disaster.
First we naturally suspected a bug in our own code or throttling changes. This led us to a code review, soul-searching, and much sweat-producing anxiety. We did solve this, and it was enlightening.
Wait for it.
Office 365 ITSELF was DOWN for all practical calendar migration purposes.
We never START with blaming Microsoft. It is with great regularity their fault, but it's better practice to look at ourselves first.
So adieu this weekend's migration into Office 365, we'll have to reschedule since as of this morning this is what the situation looks like in Service Health.
Was there any kind of alert to either THEIR administrator or say OUR Office 365 administrator that this was going down? No. I suspect there is some way to configure these, but am perfectly willing to give someone else credit for showing me how. Right now with the tension buzz just coming down I feel more in need of documenting the situation.
To the credit of the Office 365 team they did acknowledge that the system was throwing defecation at the ventilator.
The way this presents itself in a migration is that invitations will seemingly disappear. (Amended from earlier posting where I showed a DIFFERENT issue.)
Wednesday, February 13, 2013
Want to get in on the ground floor?
Drop us a line.
Sunday, January 20, 2013
Short answer: Yes you can do it. Nothing the the was we use the EWS API is specific to Exchange 2010 to the exclusion of Exchange 2007.
However, setting Permissions in Exchange 2007 IS VERY different from Exchange 2010, so you will have to adjust for that. Taking all of the Exchange 2007 permissions stuff out of the documentation made it substantially shorter and clearer,
If you need help look at posts in this blog involving Permissions and Exchange 2007.
Thursday, January 10, 2013
I was recently at a Christmas party with some people from a Redmond-based software corporation that makes Exchange. Their take: Office 365 made their lives and their customers lives much more convoluted. Where they could work solutions in on-premises servers, any changes to Office 365 need to be escalated at the corporate level. And we all know how convenient and easy that is. So they're increasingly seeing combined Office 365 and on-premises Exchange environments, precisely the opposite of what they and the customer predicted or wanted.
SO it's is with great fervor that I suggest you read Freedom for Users, Not for Software by Benjamin Mako Hill.
He hits it right on the money with his analysis of the market confusion initially arising from "free software" which was re-cast as "open software" (goals with which it is hard to disagree! What's so funny about peace, love, and understanding?) and the way this term was used and abused in the industry. The aspect that I suggest you pay closest attention to is the emphasis on users. Focused on the server-side of the client-server model, we at Sumatra would substitute the term "consumers" for "users" to avoid the further linguistic confusion that comes from the distinction between "users" and "administrators" in such environments. Both the admin and the user are consumers, and the user-admin collective together face the "user" conundrum.
After years in this business, I'm pretty sure the dynamics of the industry are never going to allow the ideals of the open software movement to be fully realized in any software that is both marketable and useful. The lure of dollars is too strong. When software remained the exclusive domain of academics and cowboys it was possible. These guys were happy to have a car and an apartment.
But once venture capital and the stock market took hold these ideals were not going to stand up to the motivation of owning a private jet and a McMansion.
What's this have to do with the movement to the cloud? It's all the same dynamic based on much of the same software with the scions of the same corporations promising freedom while actually building feudal digital fiefdoms. Do not go mindlessly with the flow when you hear that your support problems are going to go away and your life is going to be easier. You might luck out, but really look at what your business goals are and how you're going to deal with realistic software disaster scenarios while your business processes are directly under someone else's control.
As we often quote Ronald Reagan: "Trust, but verify."