Right! It's the little button that says "Z-Conflicts" just underneath "Remind Me" and "Tentative."Why have we hacked our way into the OCS client? (Windows only for now, sorry Mac and *nix users.)
Because some of you have been asking for free-busy look ups from OCS into Outlook/Exchange and Zimbra, and this is how we can do it. Your reasons are usually that you must do a phased migration from OCS rather than a "Big Bang" and the problem just seemed so perfectly up our alley.
Right now you click it and it just brings up our internal web page -- but the next step is to click it and have it offer a list of non-OCS users to check free-busy status on. When you select a time it'll drop those into the OCS external email calendar invitation interface so you can more easily customize your invitation.
We're working on the interface between migrations. Stay tuned.
The format is the same as you are used to:
zinsert -fo -tf_utc_to_timezone -cs DSN=Zimbra -post http://YOURSERVER/home/[login]/Calendar?fmt=ics -loginpwdb
will auto insert, reading the User ID and Passwords from the Users table of the database.
In the example above you see that user "Puffy Amiumi" gave the error "No TZID for TimeZone" because we had not yet mapped the Japanese OCS Time Zone to Zimbra format.
We haven't tried this with Oracle Calendar Server conversions yet but the logic should work exactly the same.
Step 1 VALIDATE your main conversion database, fix any validation issues and re-validate. You've been taken through this multiple times if you've been in the lab with Sumatra for anything beyond an hour.
Step 2 MAKE COPIES of your validated conversion database and name them something OBVIOUS, like Instance1_YourCompany_28Dec07_DB_v8.7.7.7.mdb, Instance2_..... etc.
Step 3 DISTRIBUTE accordingly to separate client machines (remember, this is Exchange 2007 and you can't run on the 2007 server)
Step 4: EXECUTE SuExchange2007.exe (aka the Sumatra 2007 Insertion Code)
Step 5: SELECT Run Multiple Instance at the "Single Instance" prompt, enter the instance number. You should clear the stats table if you've run multiple instances before. Here's a screen shot:
Background: You'll need a separate database to track the progress of each instance. We call this the "sync database", which you can think of as the traffic cop keeping all the instances running smoothly. It's usually called SyncStats.mdb.
Step 6: Point to SyncStats.mdb in the InstanceDB box.SET UNIQUE Instance Numbers for each of these before executing.
Anything preceeded by numbers (e.g., 3rdFloor Conf Rm) will automatically come at the beginning of the alphabet with A.
Keep track of these so you do not forget letters. This HAS happened in test cases in the field and it became really obvious really fast.
Next step: Analyzing your data and doing QA on the insertion.
All bets are off once sp1 hits the street -- we can almost guarantee this process will change.
First off, use ODBC (available under Control Panel) to point to the conversion database. Let's call your ODBC connection "Zimbra."
To create a series of ICS files with appropriate cross-linked GUIDs, use this command:
zinsert -fo -cs DSN=ZIMBRA -tf_utc_to_timezone
In general, converting for the appropriate time zone, use the -tf_utc_to_timezone option unless we determine another one is better (not likely, but we keep them there in case -- you never know what the US Congress is going to do with Daylight Savings Time).
Inserting into Zimbra
That's what the -post command is for, which as of this date we haven't actually had to use (also it will require knowing each user's password which is a pain)
You can use curl, or (thanks to a college in New Jersey), you can use this method.
This solution doesn't require an admin to know the user's password.
It does require a configured web server and assumes there is a separate ICS for each user calendar.
1. The ICS files need to be placed on a web server that the Zimbra server will be able to access via http (or https). I'll assume a base of http://YOURDOMAIN/migrate/.
2. Create a file (e.g. /tmp/importcals.zcs) that will be fed to zmprov with contents like this:
selectMailbox USERID1
emptyFolder Calendar <--- optional command
importURLIntoFolder Calendar http://YOURDOMAIN/migrate/USERID1.ics
selectMailbox USERID2
emptyFolder Calendar <--- optional command
importURLIntoFolder Calendar http://YOURDOMAIN/migrate/USERID2.ics
3. Run that through zmprov.
zmprov -f /tmp/importcals.zcs
We think it's easier to follow. If you're working with us it's in your FTP account.
There's a lot going on here, but don't let it scare you.
In the Email column just put your new Zimbra email
Note that even though the login for "Adam Ant" is "aant" we can substitute "adam_ant" or anything else we need so long as it matches the Zimbra address.
This simple Query will duplicate your login IDs to the Email field, appending the appropriate domain name (which you'll need or else guests will not be notified of meeting updates). Of course, this is generally modifiable into anything that makes sense for your environment.
Next step: inserting your data!
The tool that takes your exports runs in Windows and looks like this:
How do I use this?
While the design reminds you of an early farm tractor (which we are very proud of) - it's designed with the same single-minded focus: get the job done as quickly as possible and the heck with how it looks (you're tossing it out after this is done anyway).
The idea here is to take in the files you got from UNICPOUTU, and match them with users and resources from USERS.TXT and RESOURCES.TXT.
Specifically this will:
Note that if you're planning on multiple test insertions you only need to read the users and resources into the database once. It is possible to parallelize conversions, e.g., convert A-L on one machine, M-Z on another and join them together to get the job done in half the time (but please talk with us before you do that).
This also includes a blank template database (MS Access format), which we recommend you rename a copy of to something descriptive, like "December 1 migration test." Please preserve the database version in the file name; it really helps when debugging.
Let's go into some details on the specifics.
Time Zone: Select the Time Zone of your OCS node. This is really crucial otherwise everything will be off on your insertion by some multiple of hours. If you have users outside of the default time zone you can modify the USERS.TXT file for them (see earlier post).
Drop Items Prior to this Date: You can selectively export items from certain date ranges -- but in case you have a data set with everything and want to pare it down for a test insertion, you have that option here.
Threshold for recurrence patterns: When we get the events from OCS they are all individual events rather than a series. We reconstruct the series, but (as a little thinking will show you) with exceptions to recurrences this can get a little dicey. Our software analyzes the sequence and comes up with its best guess of the recurrence pattern, taking account the threshold you set.
A couple of quick things to note:
How does this work?
In two phases: the first phase reads the OCS exports and turns them into an intermediate file. The second phase reads the intermediate file into the database template.
Why not just put everything into the database as we're going along? It's faster this way.
Everything in a calendar server migration is a trade-off between time and convenience.
It's certainly easier for the average admin to work with an Access file. But the overhead of constant transactions at the volume we need is huge. Saving them for the end makes the system much faster.
Still with me? Wait a few days for Part II: Converting and Mapping your OCS data.
SO we've just added the capability to detect this in the USERS.TXT file before we get too far into a migration. If this situation arises, an error will pop up:
As we've told some of you, the tool that we used to take the OCS exports and re-create recurrence patterns (ICS as RRULES) is being re-worked for field use (as opposed to the way we used to do it in Sumatra labs). It looks like this:
with our trademark "as few buttons as possible but make all of them useful" design philosophy.
In Outlook / Exchange 2007, the same calendar looks like this (Declined and Tentative are dealt with in the Outlook INBOX rather than directly on the calendar):
Figure 2– Verify permissions at the Mailbox store
First, create two CSV (export) files - one for resources, one for users.
The script we wrote requires five columns of data – the OU, the descriptive name, the alias, the UPN, and the account type. You can build this file in Excel, or Sumatra customers can use data from the Users table. (If you’ve got a database v8.7.5.2+ from Sumatra, the query you can start with is called “N_X”.)
Here’s how each of the columns are defined:
If you are running MS Access, save the query, then right-hand click on the query name, and Export. (If you are running the N_X query, it produces a table because it “prompts” you for information. Export that table.) You want to export:
Modify the query, and repeat the export process for “resources”.
Here’s a sample export of resource account information
Import the resources. As above, remember to change the path, the OU, the DB Name.
Import-CSV "C:\Sumatra\UserExport\tmpResList.csv" ForEach-Object -Process {New-Mailbox -Name $_.Name -Alias $_.Alias -UserPrincipalName $_.UPN -OrganizationalUnit "lab.sumatra.local/resources" -DisplayName $_.Name -Database "Striper\First Storage Group\FSG_MBX_DB2" -Password $Temp -ResetPasswordOnNextLogon $false -Room:$True}
Here’s a screen shot of the results:
