Thursday, November 18, 2010
Friday, November 12, 2010
We design the process so that by the time you've created your intermediate database you should already have the email addresses for these users in the Users table.
So the brief rules are:
- Do NOTHING for OCS email addresses that are the same as in Exchange
- Add entries to the User_Adjusted_Maps table to map OCS accounts that have different Exhcange addresses
- Run the following queries Q_Build_CustIDs_From_MMUserids, Q_Build_CustIDs_AdjustMMUsersids, Q_1_Make_User_Map, FInd duplicates for MM_Exchange_User_Map
- Look at the results in MM_Exchange_User_Map
- Repeat until all of your accounts are done.
A few other things to keep in mind.
If Oracle Calendar Server IDs are THE SAME as Exchange:
- Make sure the Primary SMTP or UPN is defined as email@example.com
If Oracle Calendar Server IDs are DIFFERENT from Exchange:
- MAP the differences (Tables)
- Build the mapping table
- Overlay the changes
Once you've got all your users mapped you can just edit the mapping table. But please exercise proper handling and care with it. You do not want to be wondering which version to use when starting yoru migration at midnight on a Friday.
Wednesday, November 10, 2010
Sometimes though this gets more difficult when there's bugs in the legacy system.
One of our clients (shout out to Matt in North Carolina!), discovered some data missing from the UNICPOUTU export in their Solaris environment.
It's been mentioned a little on the OCS boards, but nobody is making a big deal about it and it is unlikely Oracle is going to fix it to make breaking your OCS habit any easier.
Thus far we've seen this ONLY with OCS 10.x on Solaris (all the 9.0.4 migration systems look absolutely peachy and we've been doing 10.x for years with no issues). We suspect it's with the very latest and is more prone to happen when the export is constrained by date (so export everything and let us segment it in our tools).
So as always, keep an eye out.
Monday, November 08, 2010
Note that this is an All Day Event (and you can specify if the time is to be shown BUSY or FREE):
While this is an appointment we've put into every calendar without any muss or fuss. You could use the same technology to do that for anything else you want (Shareholder's Meetings, Fire Drills, as your business and imagination dictate).
Any of you who have been through a migration with us know why we keep the "(Migrated)" tags, but you can decide to not use them.
This is scriptable so you can create holidays as you provision users if you have an automated system for so doing.
A few other things to keep in mind:
- This runs as an EWS application from a 32-bit workstation. So all your credentials are completely under your control. If there's demand to run this as an online service we'll listen.
- We take the default time zone of your server for all insertions. If you have users in multiple time zones and want to do this contact us -- that would be a different version.
- You can specify a single user, a list of users, or an LDAP query to handle your insertion.
Friday, November 05, 2010
Put all resources in one or more OUs for ease of administration.
PRIOR to migration:
- ENABLE all of the resource accounts via Active Directory Users and Computers
- HIDE the accounts from the GAL
- Configure resources NOT to AutoAccept meetings
AFTER the migration
- Disable the accounts and add them to the GAL
- Configure the resource for AutoAccept (if you desire first-come-first-served functionality) or
- Use group-policy settings for managed rooms and resources
Wednesday, November 03, 2010
It's the permission you need to give your service account to execute a full-state calendar migration.
Create a managementRoleAssignment:
If you have to ask where you're doing this, please go to your Exchange Administrator.