Tuesday, June 24, 2014

#Oracle Beehive to #MSExchange through a proxy -- alternate strategy

We never shy away from saying that migrations are hard.

We also never shy away from saying "Nope -- you're in over your head."

And we thought both of these were going to come to bite us as we looked at migrating Oracle Beehive from behind a proxy server.  

A set of test data we would normally expect to migrate in a few minutes was taking hours.

And there was no way to remove the proxy.

Running the calculations told us the full set of users would take four days on a single instance.  We could not put someone through that and maintain anything like guilt-free sleep patterns.  We put on our thinking caps and came up with the idea of exporting the data into a format we could use (Oracle Beehive IS a SQL database after all), taking that outside the firewall, importing it into an Oracle database, and then inserting the data (the final step herewith shown):

Problem solved.

If it's applicable to you we'll take you through it in your trial phase.

Tuesday, June 17, 2014

Oracle Beehive to Microsoft Exchange Calendar Migration: Beehive-Buddy

Oracle Beehive seems to be the legacy system folks are replacing at record pace these days.

So we've been burnishing some of the features.

Latest one: Beehive Buddy Lists.  
Any contacts tagged as Beehive-Buddy will not migrate.  This reduces the number of duplicate contacts.

Thursday, June 12, 2014

How to Stop Facebook From Using Your Browsing History

This is not about calendaring.

But let's face it, none of us democracy-loving folk want to live with the Thought Police looking at our every move.

How to Stop Facebook From Using Your Browsing History is a REALLY useful link.

Remember: if you're not paying for the product, you ARE the product (see:Season 1, Episode 11: To Heck and Back) .

Tuesday, June 10, 2014

Migrating #MDaemon Public Distribution Lists to #MSExchange

To Migrate MDaemon Public Distribution Lists to Microsoft Exchange using our tools, follow this procedure:

  1. Create a new directory to hold the processed group files.
  2. Launch the mCalReader_ParseGroupFiles application.  Browse to the MDaemon server directory for the group files (these all have an extension of *.grp and the format NAME@Yourcompany.com.grp), and the output directory from Step 1.  Ensure the file extension pattern matches your group files (Note: it defaults to @YOURCOMPANY.com.grp)
  3. Press “Go.” The processing should happen quickly. Then exit the program.  In the directory from Step 1 you should have a file called Distributionlists.csv.
  4. Move the files and the shell cmdlet “DistGroupCmdlet.ps1”  to the Exchange server (or any shared/accessible directory)
  5. Edit DistGroupCmdlet.ps1:
a. Modify $MyDistFileList to point to the Distributionlists.csv file.
                              i. Note:  the shell will create distribution lists for all entries in this file.  Remove entries that you do not want migrated/created.
b.   Modify $myMigratedOU to point to the OU that will contain the distribution lists.  Note this is a PATH to the OU, and not a typical OU identifier (e.g., ou=xxx,dc=my,dc=com),  Sample OU:, $myMigratedOU = "orca.sumatra.local/Clients/YOURCOMPANY/Lists"
6.Launch Exchange PowerShell, change directory to the location of the script and distribution list files, then run the script: .\ DistGroupCmdlet.ps1.
·         If you want to test a few distribution lists:
o   Run the EXE to parse all of the GRP files.  The EXE produces the file  Distributionlists.csv
o   Edit that file, and leave the first line (header) and only those groups you want to test.  Then,
o   Copy the Distributionlists.csv, the supporting group CSV export files, and the PowerShell script to Exchange
·         Accounts:
o   Since there is a possibility that users might not exist in Exchange, the script creates the distribution list first, then adds users to the list one user at a time. 
o   If the user does not exist in Exchange, the cmdlet throws an error but continues.
o   Also, the tool does not change any of the SMTP address domains, e.g., email addresses such as “@YOURCOMPANYmail.YOURCOMPANY.com” will be migrated as “@YOURCOMPANYmail.YOURCOMPANY.com”, and not “@YOURCOMPANY.com.”

By the way, this was field-proven as the last stage of a migration at a 300 user site over this past weekend.