Goodbye Exmerge, hello Export-Mailbox, but be careful

Posted on by
Reply

Exmerge was a very useful free Microsoft tool for those of us who worked with Exchange 2003.  I recall many instances whereby I relied on it to resolve a few nasty support issues.   It was dependable, and had lots of useful features.   But Microsoft dropped it for Exchange 2007 and Exchange 2010.

Its replacement is a Powershell cmdlet called “export-mailbox” which is well documented elsewhere on the internet, such as Microsoft Technet.   This blog article does not aim to explain how to use all the different options and features.    The aim of this blog is to warn Exchange Administrators of a potential risk when using the “export-mailbox” cmdlet, which is not explained clearly elsewhere.

As an example, if you were asked to remove all emails that matched a particular subject line from a list of mailboxes on Exchange 2007/2010, and to also capture any messages that were dropped, then you could use the following Powershell cmdlet:

Import-CSV “C:\temp\input_list.csv” | ForEach-Object -Process {Export-Mailbox -Identity $_.PrimarySMTPAddress -SubjectKeywords “example subject line text blah” -Deletecontent –StartDate “01/03/2012″ -EndDate “15/03/2012” -TargetMailbox exaudit -TargetFolder auditfolder -confirm:$false}

Follow this approach …

Compile a CSV File:

Compile a CSV file listing all the mailboxes that are to be scanned.  Ensure the header line is the required column header “   PrimarySMTPAddress   “. Without the quotes.   All the mailbox values here are represented by smtp addresses.   The start of the input_list.csv file will look like this:

PrimarySMTPAddress

Fred.smith@contuso.com ,

John.smith@contuso.com,

Create a Target Mailbox to Audit Results:

Create a target mailbox, into which the log activity will be recorded for each mailbox scanned.  This will also leave behind any offending emails captured in the search, to allow for a report to be made at the end of the task, for audit purposes.  Create new root folder in the mailbox called auditfolder  .

Get Permissions to the Mailboxes to Scan:

To run the “export-Mailbox” cmdlet, use an Active Directory account (with a mailbox) that has full rights to all the mailboxes (or all mail databases) via the “add-adpermission” cmdlet.   This Active Directory account cannot be a Domain Admin account, as Exchange tags those with explicit Deny permissions.

Test your cmdlet:

It is a good idea to run the cmdlet first with only one mailbox listed in the input_list.csv file, as a test run.   You will see a folder structure be created for the mailbox being scanned within the exaudit mailbox, under the auditfolder .   If this test fails to run a common problem is lack of Full Access permissions to the mailbox you are trying to scan.

Ready to Run:

Once your test run was successful you are ready to run with the remaining mailboxes in your list.  You can do this via a single thread using one Powershell window, or you can chop your list into four parts, and run each part within its own Powershell window.  The “MaxThreads” cmdlet parameter does not work when you pipe an input list into the “export-mailbox” cmdlet.  Hence the workaround of running multiple Exchange Powershell windows.

The Gotcha:

The gotcha to be wary of, and the biggest one, is if you are scanning a large number of mailboxes, you must watch out for Transaction Log growth on the Database on which the exaudit mailbox sits.  This is because part of the way “export-mailbox” works is via a “move-mailbox” operation into the Target mailbox, which generates Transactions.      If you scan 80GB of mail data, and your Transaction Log volume only has 60GB free space, then you will run out of disk space, causing that Exchange Database to dismount.     Not good !

It may be hard to estimate how many Transaction Logs you will generate, so there are steps you can take to mitigate this risk.  Firstly, you can use Date Filters where possible, as only messages within that date filter will be moved to the Target mailbox (tip – match the date format you use in the cmdlet to the date format in the local Exchange Server Regional Settings).   Secondly, and safer, is to place the Target mailbox (exaudit in this case) on its own dedicated Exchange Database, and to enable Circular Logging – to prevent Transaction Logs building up – this provides peace of mind, and allows large lists of mailboxes to be scanned.

“Export-Mailbox” is a very powerful Powershell cmdlet, and greatly improves on ExMerge’s capabilities.  However, it also requires a bit more planning to use safely in an enterprise environment.  As ever, do your testing in a lab environment first !

Planning for a migration from Domino to Exchange – getting your ducks in a row

Posted on by
2

We hear about the Vice President who was supposed to migrate last night. The Access Control List for his mail had been changed and only some calendar entries had come across. The migration team now has to quickly react and fix the ACL and then redo the migration. Would it not have easier to identify the ACL issue weeks ahead of time?

We find that there is a user who had set his mail file to encrypt all incoming mail. We get help desk call that says after migrating that all of his emails are blank. Sometimes we find that all of the mail files in the HR Department are encrypted. Sometimes we find that there are one or two emails that are encrypted. The planning for the migration needs to be different in either of these situations. We need to examine the Domino Directory and the mail files to identify which situation we are up against.

For the user who has 160 mail rules, he calls the Help Desk and wonders where his rules have gone. He is told that the migration software doesn’t migrate rules. Alternately, we could scan all of the mail files and identify these individuals. Then we can print out the mail rules and tell him ahead of time that he will have to recreate the rules.

Contact us and we can help you with a pre-migration inventory at the early planning stages.

Offline Domino Migration to Exchange 2010, with Quest Notes Migrator to Exchange

3

Recently I was asked to show a company how to migrate from Domino to Exchange 2010 using Quest Notes Migrator to Exchange.    Having done a number of these migrations before, I was looking forward to drawing upon my past experiences to give them a good understanding of the process.

The company had their own in-house IT staff who would be doing the actual migration, and only needed my help to setup a test environment, perform some test migrations, produce detailed documentation, and then build out a production Quest Notes Migrator to Exchange server – for them to use for the migrations at a later date.

However, it soon became clear that there was a major constraint to the migrations – there would no network access to the legacy Domino Servers from the Quest Notes Migrator to Exchange server !  The company had been sold off from their larger parent company, who managed the Domino environment, and bought by a completely new parent company, who managed an existing Exchange 2010 environment.   The only Domino data provided to the Quest Notes Migrator to Exchange server would be an offline copy of all the user Lotus Notes mailbox NSF files – arriving on an external hard drive.  Users still had access to their legacy Lotus Notes mailboxes for a few weeks, until the legal cut-over date, at which time this would be halted.

This scenario goes against a number of the requirements listed within the documentation for the Quest Notes Migrator to Exchange product.  Examples are:

  • Lack of Domino administrator ID file
  • Lack of network access to any Domino Server

Quest Notes Migrator to Exchange Install:

The Quest Notes Migrator for Exchange installation went smoothly on a Windows 2008 R2 virtual server, on the company’s new network.   I went for a local SQL Express 2005 SP3 setup, with the 64-bit SQL Native Client.    Outlook 2010, Lotus Notes 8.02, Exchange Management Tools were all installed successfully.  Outlook 2010 received a MAPI profile for an existing “quest” Exchange 2010 mailbox.  Lotus Notes client was not configured at this time, as there was no access to a Domino Server.

On starting up the Migration Manager program within Quest Notes Migrator to Exchange, I was able to configure the required values for SQL Express, logging folder shares, Exchange 2010, and Active Directory.  However, I was not able to configure any Migration Manager settings for Domino – such as for Notes Address Book, ID file, Domino Server name – as there was no access.

At this point I had done as much as possible without having to connect to the Domino Server, and was unable to make us of any of the migration features within Quest Notes Migrator to Exchange, as the local SQL Express Database did not contain any rows for the Domino Directory objects.  So no Collections could be created, which means no migrations could take place! 

I will try to get some screenshots to add in to this procedure later on, to break up the text a bit !

Quest Configuration for Offline Migration:

The good folks at Quest pointed out that there is an offline migration procedure described in the documentation, intended mainly for a lab environment.  This sounded promising, so I set about trying to make it work.

The first thing that was needed was to grab a production Notes ID file and password off one of the company employees who still had a working Lotus Notes mailbox.    The Lotus Notes client on the Quest Notes Migrator for Exchange server then required its Lotus Notes client to be configured to run in Island mode (disconnected) for that user.  The easiest way to achieve this, without having to run through the Lotus Notes start-up wizard, was to copy the user’s Lotus Notes program folder over the top of the Lotus Notes program folder on the Quest Notes Migrator to Exchange server.   Care was needed to ensure that the local install folder matched the one used on the user’s workstation – for example c:\lotus\*   .   Then start Lotus Notes on the Quest Notes Migrator to Exchange server, and it should show the user’s name, and prompt for the user’s Lotus Notes password, and then load up in Island (disconnected) mode.

So far so good !

Next, within Migration Manager, populate the user’s ID file and password details in the Domino credentials section.  For the Domino Server field just enter NULL , as this is a free format field that will take any value .   Apply these changes, and no error should be displayed.   We are now one step further forward, but are now presented with the next hurdle, which is the Notes Address Book (NAB).

Migration Manager needs to read in the contents of an identified Notes Address Book, and copy the data into its local SQL Express Database.   The only way to solve this was to ask the identified user to login to their legacy Lotus Notes mailbox on their workstation (this is the same Lotus Notes ID context as within Migration Manager), and create a local replica of the Domino Directory into a local address book file.   You may need to force replication to speed this bit up.  Once done, check the file system for the new address book file, and transfer it onto the Quest Notes Migrator to Exchange server somehow.

On the Quest Notes Migrator to Exchange server start Lotus Notes and try and open the replica copy of the Domino Directory local address book (created earlier).  This should open successfully as you are using the same Lotus Notes ID security context as used to create it.  Exit out of Lotus Notes, and go into Migration Manager.   On the screen where you typically select the Notes Address Book, instead use the Browse button to access the file system, and browse to the local replica of the Domino Server Directory address book.   This should open successfully, and will list all the SMTP namespace domains it finds.   Pick one SMTP namespace as the default – any will do.  Next, you can use the Export Directory option to download the contents of the local replica of the Domino Directory address book into the SQL Express Database.

When the Export Directory step has been completed, you are almost ready to migrate some offline data.   A final step that is required is to make a change to the global ini file within Migration Manager.   You need to add the following line into the [Notes] section:

Offline=1

Then close down and re-start the Migration Manager application.   This allows Migration Manager to run in what Quest calls “offline mode”.   This will allow the Migrate User Data process to run without having to validate a connection to a Domino Server.

If you have managed to complete all the above steps you are now ready to think about migrating some offline Domino mail data !  

You can now think about how to actually migrate the offline Domino mailbox NSF files into PST files, or directly into Exchange 2010 mailboxes.  

Offline Domino Data Migration Procedures:

You may be asked to migrate the following types of offline Domino data:

  • User mailboxes
  • User archive files
  • User Personal Address Books
  • Mail-In Databases
  • Rooms and Resources
  • Mail Groups

I will summarise how to approach the migration of all the above types of Domino data when Quest Notes Migrator to Exchange is offline from the Domino Server.

User Mailboxes Offline Migration:

As you are disconnected from the Domino Server you need to ask the Domino Administrator to do some preparation work on the NSF files before you receive them.   (And get the Exchange administrator to create new mailboxes for everyone required).  The Default Notes ACL permission needs to be opened up to be Manager for each NSF file.   Also, ideally, only the primary user of each NSF file needs to be listed in the Notes ACL as Manager also.   This allows you to then create a Collection for the required users, and run the Locate Notes Data wizard against the files – to allow Migration Manager to work out which file belongs to which user, based on Notes ACL.   Once this is done, you can then attempt to use the Migrate User Data wizard to actually migrate the data.  Migrating to a PST file is the easiest output option to use, but you can migrate directly into the target Exchange 2010 mailboxes – but you need to ensure that the legacy Domino internet address for each user is listed as one of the SMTP addresses against each user within Exchange 2010 (Migration Manager uses this to establish the relationship).   If you hit any issues with finding the target Exchange 2010 mailbox, it is best to just migrate to PST file, and use Exchange Management Shell to import the PST files into the correct Exchange 2010 mailboxes later.

User Archive Files Offline Migration:

Typically these files will be on the legacy local workstations that were being used by the employees running the Lotus Notes client.   User communications will be needed for each user to open up and change the Notes ACL on all of their Archive files – they need to change the Default ACL to be Manager (this is needed otherwise Migration Manager will be unable to access the Archive Files to work out which one belongs to which user.)

 A process is required to copy the files off the workstations onto a network share that the Quest Notes Migrator to Exchange server can access.   You may need to use an External Hard Drive to move the files between the two environments.   Create the Collection in Migration Manager, and run the Locate Notes Data wizard against the file share containing the Archive files copied over from the legacy environment.  This should be able to work out which file belongs to which user.   Then use the Migrate User Data option in Migration Manager against the same Collection to convert the files to PST.  Once the PSTs are generated you can decide how to distribute them.  Note: you do have the option of migrating this data directly into the Exchange 2010 Mailbox, or even directly into the Exchange 2010 Personal Archive Mailbox, for each user. 

If any Archive file is not migrated, check the log files, and also try and open it from the Lotus Notes Client on the Quest Notes Migrator to Exchange server.  If it cannot be opened in this Lotus Notes security context then it cannot be migrated.  If you can open it, you should check the Notes ACL to see if the primary user is listed as the only other Manager ACL role.  Multiple users listed as a Manager ACL role may cause issues.

User Personal Address Books Offline Migration:

These need to be treated the same way as the Archive files described above.  The only difference is that there may be more business pressure to have these files migrated earlier, and with a higher success rate.   Being local files, and having to rely on user actions, may hinder meeting these expectations !

Mail-In Databases Offline Migration:

Any offline NSF files received from the Domino Administrator can be treated in a similar way to user mailbox NSF files.  The only difference is that you cannot use the Notes ACL to determine the primary user for each file, as typically, multiple users will use each one.    The choice here is to either migrate all of them to individual PST files first, or to use the MailFilePath column in the Collection to explicitly list the unc path (and file name if not in unique folder) to each NSF file (export to TSV to see it, edit the paths, re-import TSV into Collection).   The Exchange Administrator will need to create new AD user accounts and Exchange 2010 mailboxes for each Mail-In Database instance, and also setup the required security model for each.  Users can use the Outlook 2010 “Add Account” option to access any required migrated Mail-In Databases (normally called Shared Mailboxes in Exchange-speak).

Rooms and Resources Offline Migration:

These exist in Domino within one Database NSF file, and not in separate NSF files for each Room & Resource.  Therefore you cannot do an offline migration for these object types (well, I am not aware of one) !   The only option is to get a list of ones you used from Lotus Notes, and give this to your Exchange Administrator for them to create new instances of each within Exchange 2010.  No legacy appointments will be migrated in this offline scenario.  Users will need to re-create any required appointments from their Outlook 2010 client. 

Mail Groups Offline Migration:

The Migration Manager Groups Provisioning tool can be used in the normal way to provision any Mail Groups that are listed in the Domino Directory, as these are all captured in the local replica Domino Directory address book file loaded into Migration Manager.   Place them in a dedicated AD OU, and review them afterwards in case you wish to make changes.  

GroupWise Migrations to Exchange 2010 vs Quest GroupWise Coexistence Manager – thoughts …

Posted on by
1

Migrating off Novell GroupWise onto Microsoft Exchange 2010 has always presented a few challenges to overcome – especially if you are trying to produce a robust Migration Strategy on how to do it.

Back in the days of Microsoft Exchange 2003 you could leverage the Microsoft GroupWise Connector to inter-connect the two systems, and this gave you the minimum two functions (in my opinion) required for a migration:

  • Directory Synchronisation
  • Mail Flow

Plus, the luxury of an additional function – if you needed it:

  • Free Busy lookups

Then you could use the excellent Quest GroupWise Migrator tool to actually migrate the email data off GroupWise onto Exchange.   This tool costs money, but for any deployment over 500 mailboxes I would not consider anything else.

Exchange 2003 is not commonly used now for Novell GroupWise to Exchange migrations, but if it is, then you can use it to help you, and it is free – which is always good.   The connector has quite a few bugs, and is not that reliable, but if managed closely can allow you to achieve a successful migration.

When Exchange 2007 came along, Microsoft provided the Microsoft Transporter Suite for Lotus Notes migrations, but did not bother developing an equivalent tool for GroupWise.   They must have under-estimated the number of GroupWise customers out there – quite a few left I think !   Anyway.  No matter, as you could always provide for an Exchange 2003 Bridgehead server in your Exchange 2007 Organisation, and then make use of the Exchange 2003 GroupWise Connector.  This was extra work, but still possible.  And of course, the Quest GroupWise Migrator tool is still my number one choice for the email data migration.

With the arrival of Microsoft Exchange 2010, the above method was no longer such a viable idea, as the amount of technical effort involved to have an Exchange 2003 Bridgehead server in your Exchange 2010 Organisation is considerable, as is the effort to remove it afterwards.  Plus, Microsoft stopped supporting the Exchange 2003 GroupWise Connector a long time ago.   Overall, far too risky to use in my opinion.   Quest, meanwhile, are still regularly maintaining their GroupWise Migrator tool for the email data migration part.

By using the Quest GroupWise Migrator tool, for a GroupWise to Exchange 2010 migration, you can just about achieve a successful migration.   You can place SMTP connectors between the two environments for mail flow, and you can leverage the Quest GroupWise Migrator tool’s “Group Provisioning” tool to force DirSync contacts to appear in Active Directory (&Exchange) if required.   Adding any Exchange addresses into GroupWise might need a manual process, but it is all very doable.   There is no free busy lookup though.    This means you need to adopt a “rapid” migration strategy for these migrations as coexistence will not provide a good user “experience”.  Any email migration consultant (who knows his stuff!) should be able to get all this working nicely.

Quest have just announced a new tool, called Coexistence Manager for GroupWise (CMG), which aims to plug the gap left when Microsoft stopped developing the Exchange 2003 GroupWise Connector.  This tool is similar to their successful Coexistence Manager for Lotus Notes (CMN), and opens up additional Migration Strategy options for a GroupWise to Exchange 2010 migration.   The three main components of the Coexistence Manager for GroupWise (CMG) are:

  • Free Busy lookups in both directions
  • Mail Flow between both environments, preserving Calendaring message formats
  • Directory Synchronisation between both Address Books

Each component is advised to run on its own Windows Server.   The mail flow component requires all email traffic is routed via itself to ensure that Calendar-type messages are picked up, and processed properly.    The Directory Synchronisation component removes the headache of having to provide an adhoc (manual) solution to keeping the Address Books up to date.   And the Free Busy component allows for a longer co-existence period for your migration.

See the full product details on the Quest website with this >>link.

In summary, the Quest CoExistence Manager for GroupWise product is very powerful, and should be considered for your enterprise GroupWise to Exchange 2010 migration, along with their GroupWise Migrator product. Check the CMG product documentation closely as it does list some restrictions, such as it only working with GroupWise 8.02 upwards.    If budget is an issue, you may be able to manage with just their GroupWise Migrator product, and live without the CMG “extras” such as Free Busy lookups, and also do some extra work for the Address Book synchronisation.  Good to see Quest produce such a useful product set where Microsoft didn’t think it was worth the effort. I look forward to finding time to read through all the product documentation, and having the chance to use the product. At least we now have some (nice) choices to make when planning for a GroupWise to Exchange 2010 migration.

 

Migrate Domino Mail-In Databases to Exchange 2010 Group Mailboxes – Random Notes from the Field

Posted on by
Reply

On a recent Domino R8.5 to Exchange 2010 email migration, using the Quest Notes Migrator to Exchange (QNME) tool, I had to migrate a large number of Domino Mail-In Databases to equivalent Exchange 2010 Group Mailboxes, whilst minimising any business impact.  Not an easy task.

The Domino Mail-In Database migrations had been left until last, after all user mailbox migrations had been completed, with Mail-In Database access provided via user’s legacy Lotus Notes client. 

Tip: for a Domino to Exchange migration it is always a good idea to provide user access to the legacy Lotus Notes mailbox – it solves many headaches.

Leaving the Mail-In Database migrations until last proved to be a smart move, as by the time we got to the migration of the Domino Mail-In Databases, the users were all comfortable using Outlook 2010, and therefore, less resistant to the changes they would experience when the Domino Mail-In Databases were migrated.

In this article, the phrases “Mail-In Database” and “Group Mailbox” are interchangeable.  “Group Mailbox” is the commonly used descriptor within Exchange 2010.  These mailboxes could also be referred to as Shared Mailboxes.  Pick a terminology that user’s are comfortable with – using new terminology can be a source of confusion during the email migration project, and is best avoided if possible.

The remainder of this article covers a typical Domino Mail-In Database migration process to Exchange 2010, and also the applying of required ACL permissions post-migration.

Example Quest Mail-In Database -> Group Mailbox Migration Process

We migrated the Mail-In Databases to Exchange 2010 using our standard Quest NME process, which can be summarized as:

  • Ensure DirSync AD Mail Contacts existed in Active Directory (AD) for each Domino Mail-In Database.
  • Create AD user objects, in a separate AD OU, for each Domino Mail-In Database, with the correct SMTP address in the General|Email Address field.  Set a standard, secure, password on this new AD user objects, as no one should be logging on directly with the AD accounts.
  • Use QNME Group Provisioning to ensure all Domino “Mail” and “Multi-Purpose” Mail Groups are provisioned into an AD OU.
  • Use QNME to merge the Domino Mail-In Database AD Mail Contacts into the AD user objects, for each Mail-in Database (Group Mailbox).
  • Use QNME to mailbox enable the AD mail-enabled objects for each Mail-In Database.
  • Use QNME to place an email forwarder on the legacy Domino Mail-In Database instances, pointing to the new Exchange 2010 mailboxes.
  • Use QNME to migrate the mail data from the legacy Domino Mail-In Database instances into the new, matching, Exchange 2010 Group Mailboxes.

As a test, you can now grant yourself access to any of the migrated Group Mailboxes in Exchange 2010, and open them up with an Outlook 2010 Profile – to check that the migration worked as expected, and that the Group Mailbox functions as planned.

QNME was configured (via the parameter ini file) to not migrate the Access Control Lists (ACLs) across from Domino, as we had found the ACL migration results in this area problematic, and also did not want all the “Domino system” ACL entries to be stamped on the Exchange 2010 Group Mailbox instances from Day 1.   Therefore, we had to plan for a standard process, post-migration, to put the required Group Mailbox ACL permissions in place.

Apply Exchange 2010 Group Mailbox ACL Permissions

We were now ready to apply the ACL to each Exchange 2010 Group Mailbox.   In my experience, you would typically find a Domino “Multi-Purpose” Mail Group that was used to provide Manager access for users to the Domino Mail-In Database instance.  This Domino “Multi-Purpose” Mail Group should have been provisioned in AD via the QNME Group Provisioning tool, which allows you to use it to apply the ACL to the matching Exchange 2010 Group Mailboxes.

Note: It is important that any such Domino “Multi-Purpose” Mail Groups are provisioned in AD as Universal Security Groups (USG), and not as Universal Distribution Groups (UDG).   This is a QNME Group Provisioning setting that can be modified, if required.   You cannot use a UDG as an ACL for an Exchange 2010 Group Mailbox.  Check in ADUC that the Distribution Lists (DLs) are set as USGs.

Mail Enabled AD Group Types: USG vs UDG

For the ACL, I strongly advise that the following permissions are applied under Exchange 2010, as these closely match the typical Domino permissions:

 

  • Full Access – for an identified AD USG
  • SendAs – for an identified AD USG

I advise staying away from adding in any granular Group Mailbox ACL permissions for individuals, or other USGs.   It is easier to manage one USG for each Exchange 2010 Group Mailbox.   If anyone needs access to the Exchange 2010 Group Mailbox, then they get added to the matching USG.    This has the additional benefit of being able to grant identified users the ability to manage the USG membership via their Outlook 2010 client – which is likely to have been the behaviour under Domino.  And it keeps things simple for support purposes – equally important.

The Full Access and SendAs permissions can be granted in two different ways.   The first method is via the Exchange Management Console (EMC).

You simply right-click on the Group Mailbox and select Manage Full Access Permission…

Manage Full Access Permission

 

 

 

 

 

 

 

and select the required Distribution List (USG, not UDG).  Then do the same but for Manage Send As Permission…

Manage Send As Permission

Doing each of these will give you the opportunity to sight the Exchange Management Shell (EMS) equivalent command that is used – which is useful information if you wish to do these steps via EMS, and not EMC.

The second method, via EMS, is best used if you need to apply ACL permissions to a large number of Group Mailboxes on Exchange 2010, and you can even use a CSV file as an input.

 

Apply Full Access Permission in EMS:

A typical example one-liner to apply the Full Access permission to an Exchange 2010 Group Mailbox is as follows:

Add-MailboxPermission -Identity “CONTUSO\TestGroupmbx” -User “CONTUSO\TestGroupDL” -AccessRights FullAccess

AD Windows Shortname for a Mail Group

The above example grants the DL called “TestGroupDL” the FullAccess permission to the mailbox called “Test Group Mailbox”.  Note the use of the NETBIOS (or shortname) of each object, and also the “-user” value referring to a DL object.

 

 

Apply SendAs Access Permission in EMS:

A typical example one-liner to apply the SendAs Access permission to an Exchange 2010 Group Mailbox is as follows:

Add-ADPermission -Identity “CN=Test Group Mailbox, OU=Users,DC=Contuso,DC=com” -User “CONTUSO\TestGroupDL” -ExtendedRights send-as

The above example grants the DL called “Test Group DL”, with shortname TestGroupDL, the FullAccess permission to the mailbox called “Test Group Mailbox”.  Note the use of the full canonical name (CN) of the Test Group Mailbox.  And the use of the NETBIOS (or shortname) of the Distribution List.   This is different from the format used for the earlier Full Access permission being applied.  Note that the parameter “-User” in this example is actually the DL name.

Each of these one-liners could be copied and pasted into the EMS shell window, or they can be saved as a text file, with a .ps1  suffix.  This allows you to run the .ps1 file under EMS.  That way, you could list multiple lines of code in the .ps1 file.  It would be best to have a separate .ps1 file for the Full Access permission cmdlets, and another one for the SendAs Access permission cmdlets.

Add “Full Access” Permissions via EMS Script with CSV Input File:

The final alternative, if you have a very large number of Group Mailbox permissions to apply, is to use a CSV file as input into each of the two different command functions.

Below is an example EMS cmdlet you could use here to grant the Full Access rights to a large number of Group Mailboxes to different Mail DLs.

Import-csv c:\temp\fullaccess_input.csv | foreach {Add-MailboxPermission -Identity $_.MBXNAME -User $_.DLNAME -AccessRights Fullaccess -InheritanceType all}

The CSV file would have two columns, with a header of MBXNAME and DLNAME for each – with the required data underneath the headings.  Do this in Excel, populate the values, and save as CSV (I use the DOS CSV option in Excel).

Example CSV Input File for Granting FullAccess Permission

Do not forget to ensure the canonical name is used in the appropriate column. No need to place quote marks in the data values in the spreadsheet – they are placed automatically by saving the file as a CSV type.

Note: one annoying Microsoft glitch I found when granting “Send As” permissions in EMS was that the cmdlet succeeded even when the DL Group I was using as the ACL was a mail-enabled UDG, and not a USG.  In EMC if you try and do this, you are unable to, as the browse list only shows mailboxes and mail-enabled USGs.  However, the EMS command does not prevent you from doing this, and even shows up afterwards when you run a “Get-Mailboxpermission -Identity ….” cmdlet.  It will not work however, which is at least something.  It is confusing though.   You need to remove it, via “Remove-Mailboxpermission…. ” cmdlet, and make the DL Group a USG instead.

Add “Send As” Permissions via EMS Script with CSV Input File:

Below is an example EMS cmdlet you could use here to grant the SendAs rights to a large number of Group Mailboxes to different Mail DLs.

Import-csv c:\temp\sendas_input.csv | foreach {Add-ADPermission -identity $_.MBXNAME -user $_.DLNAME -ExtendedRights Send-As}

Example CSV Input File for Granting "Send As" Permission

The CSV file would have two columns, with a header of MBXNAME and DLNAME for each – with the required data underneath the headings.

Do this in Excel, populate the values, and save as CSV (I use the DOS CSV option in Excel).   Do not forget to ensure the canonical name is used in the appropriate column.   No need to place quote marks in the data values in the spreadsheet.  They are placed automatically by saving the file as a CSV type.

Adding Exchange 2010 Group Mailboxes to Outlook 2010 Profile

You are now ready to add the Group Mailbox to the user’s Outlook 2010 setup.  This can be done with the new Add Account feature within Outlook 2010, which avoids the previous method of adding via the Outlook MAPI Profile.  See my blog entry on this topic by following this link>>.   For this level of Group Mailbox functionality, users are better off using the full Outlook 2010 client, and not Outlook Web Access (OWA).  OWA does allow for Group Mailboxes to be accessed, and used, but the experience is not as rich.

Conclusion

This method will be more likely to be aligned to how Group Mailboxes (and ACLs) were setup within Domino, including the presentation to users within the Notes Address Book.   Planning to overhaul the way Exchange 2010 Group Mailbox permissions are applied, as part of the email migration, is not a wise move, in my opinion.

Use the objects, and permission structures, that are migrated from Domino to get the equivalent functions working in Exchange 2010.  Users will be more familiar with these object names.  If you wish to introduce new standards, then do so for any new Exchange 2010 Group Mailboxes that are requested.   That way you have minimised the business impact.

Also, check to see if users in Domino had access rights to change any Mail-In Database ACL Group membership, and if they did, grant them this same access right within Exchange 2010 for the matching AD USG.  See my earlier blog article on this topic by following this link>>.

Thanks for reading, and I hope some of the information will be of use.  Please make a comment, or provide feedback.   Don’t forget to test first in your lab environment, especially when running EMS commands.

 

Decision Process for moving to the Exchange 2010 Cloud

Posted on by
Reply

Your company may be considering moving to a Hosted Exchange 2010 Cloud solution.    Technically, you need to be across the implications of this, and need to communicate back to the business what, if any, the risks are.

Have a read of my article on this topic under a new Cloud section of this website.

Go to Hosted Exchange 2010 Cloud Considerations for a read.   Comments are welcome, as keen to start a debate on this one.

Emailmigrations.com Website Refresh

Posted on by
Reply

I was getting a bit tired of the orange colour scheme with the migrating birds header image, so I decided to change things around a bit.   Hope you like the new look, with some new social media widgets down the right hand side, a new colour scheme, and a new header image.   If you think you know which place in the world is shown in the header image, please let me know !

Please provide any general feedback on the look and feel of the website, as keen to make it as user friendly as possible for everyone.

Emailmigrations.com changes Web Hosting Provider to BlueHost

Posted on by
Reply

Not strictly related to email migrations, but there has been some minor disruption over the last week as I changed web hosting providers from GoDaddy to BlueHost.   If you were trying to use the website during this period, I apologise for any disruption.    The website had begun to slip down the Google page rank scale, and after investigating why, I decided the best action was to move hosting providers.    Without going into too much detail, my previous hosting provider seemed to in the habit of using invalid redirect urls within my website, which were listed as being bad in Google Webmaster Tools.

WordPress recommend BlueHost, and the whole transfer process was very smooth, and I am now enjoying accessing all my web hosting technical options via the BlueHost cPanel facility – which places them all together in one place.  So far so good, and I look forward to getting my Google page rank back up to where it was a few months back, and I am happy to recommend them for domain hosting.

 

Generating an SMTP WhiteList in Exchange 2010 via EMS Script

Posted on by
Reply

On a recent Domino to Exchange 2010 migration project the customer was using the an Edge Message layer product that had an SMTP Whitelist configured.   This allowed only email sent to (and from) authorised SMTP addresses to pass through the Edge Message layer.   The scenario described is not uncommon as some companies only allow a subset of their employees to use internet email from their internal mailbox.  A typical Edge Message layer may be running Postfix or Symantec MessageLabs, for example.

For the email migration project I was working on, the customer had a Domino Mail-In Database configured (with a Domino Agent) to send a scheduled email to a set mail address (hosted on the Edge Message layer system) that contained all the valid SMTP address of Domino mail objects.  The list contained only primary SMTP addresses in one column with no header and no EOF character.   The Edge Message layer system then imported the SMTP addresses into its SMTP Whitelist.

As part of the email migration I had to move this function off Domino onto Exchange 2010, otherwise we would be unable to decommission Domino at the end of the email migration.

After spending the usual half an hour searching on the internet I could find no clear example(s) of how to achieve this.   So I had to work it out for myself, and decided it may be useful for other people out there who need to use a similar SMTP Whitelist function.

I managed to develop two ways of presenting the Whitelist: firstly the SMTP addresses were attached to an email in a text file, and secondly the SMTP addresses were embedded in the message body.   Either variant may be useful.

Also, I did a further version which excluded Mail Group SMTP addresses where the Require Sender Authentication setting was enabled, as Exchange would reject internet emails being sent in to these addresses anyway.  So no point cluttering up a SMTP Whitelist with such addresses.

I researched EMS commands, CSVDE, DSQUERY, and DSGET.  Finally I decided to go with a hybrid approach which combined a series of DSQUERY commands, some DOS batch commands, and an EMS Powershell SendMail call.    All these parts can be placed into the one central DOS batch (.bat) file.  The only other file required is a .PS1 EMS script to execute the SendMail function at the end.

Be aware that this solution does not cater for secondary SMTP addresses – I will research this extra requirement if someone requests it !

The solution can be broken down into sections:

Section 1 – DSQUERY Commands

Three DSQUERY commands were needed in order to extract (to a text file) the primary SMTP addresses for the following three object types: Mail Contacts, Mail Groups, Mailboxes.

dsquery * -filter “(&(objectCategory=person)(objectClass=contact)(mail=*@contuso.com))” -attr mail -limit 0 >smtp_contacts.txt

dsquery * -filter “(&(objectCategory=group)(objectClass=group)(mail=*@contuso.com))” -attr mail -limit 0 >smtp_groups.txt

dsquery * -filter “(&(objectCategory=person)(objectClass=user)(mail=*@contuso.com))” -attr mail -limit 0 >smtp_users.txt

Section 2 – Remove Line 1 Column Header Line from Text (TXT) Files

Each of the above export files contained a header line (column header) which needed to be removed as the Edge Message Layer requires raw SMTP addresses only.  To do this we need to lean on some DOS batch file wizardry, which re-writes each Text file to a new Text file, but minus the first line.

for /f “skip=1″ %%A in (smtp_contacts.txt) do ( echo %%A >> contacts.txt )

for /f “skip=1″ %%A in (smtp_groups.txt) do ( echo %%A >> groups.txt )

for /f “skip=1″ %%A in (smtp_users.txt) do ( echo %%A >> users.txt )

Section 3 – Merge the Text Files together into a single Text File

More DOS batch commands to achieve this.  Use the following command.

copy /b contacts.txt+groups.txt+users.txt SMTP_ALL.txt

Note the use of the “copy /b” command, which treats the Text files as Binary files.   This is required to stop the EOF character appearing at the end of the resultant text file.

Section 4 – Initiate a SendMail EMS task

Use this call to run the EMS Powershell batch command to send the SMTP_ALL text file to the required target mailbox.

Powershell -command “& {C:\Scripts\whitelist\sendmail_whitelist.ps1 }”

Section 5 – SendMail EMS Script

Create a .PS1 file to contain the EMS script to send the email to the required target mailbox.  I called my .PS1 file SENDMAIL_WHITELIST.PS1  .  The script is shown below.   You will need to enter your internal mail relay IP address details, a valid From address, and the target SMTP address you want to send the WhiteList to.  Note that I have placed the SMTP_ALL.TXT file into C:\TEMP  .  You will need to change this path for your environment.

#Send an email

$FromAddress = “postmaster@contuso.com”

$ToAddress = “admin@mail.edgeservice.com”

$MessageSubject = “Whitelist SMTP List”

$MessageBody = “Attached is EPS SMTP Whitelist”

$SendingServer = “xxx.xxx.xxx.xxx”

$SMTPMessage = New-Object System.Net.Mail.MailMessage $FromAddress, $ToAddress, $MessageSubject, $MessageBody

$Attachment = New-Object Net.Mail.Attachment(“c:\temp\SMTP_ALL.TXT”)

$SMTPMessage.Attachments.Add($Attachment)

$SMTPClient = New-Object System.Net.Mail.SMTPClient $SendingServer

$SMTPClient.Send($SMTPMessage)

Section 6 – Put it all together

I have not posted the complete DOS Batch script here, as you should be able to use the information provided to put together your own version.  I called mine from a Windows Server running Exchange 2010 Management Tools, under Scheduled Tasks to run one a day.   Also, you may need to run the Exchange 2010 Remote Execution Policy powershell command – this is widely documented if you need to find it.

Hope you found this useful.  Not an everyday requirement, but I am sure that if I stumbled across it, then at least one other person out there will do also !

Section 7 – Extra Development Bits

This section provides some advanced variants to the above solution that you may find useful.  I am no script expert but was able to work this one out after a few hours, as could find the solution I wanted elsewhere on the internet.

The first variant places the SMTP Whitelist into the message body of the email that is generated via the EMS Powershell script.   The new version of the EMS script is below:

#Send an email

$scr = type SMTP_ALL.TXT | out-string

$FromAddress = “postmaster@contuso.com”

$ToAddress = “admin@mail.edgeservice.com”

$MessageSubject = “Whitelist SMTP List”

$SendingServer = “xxx.xxx.xxx.xxx”

$SMTPMessage = New-Object System.Net.Mail.MailMessage $FromAddress, $ToAddress, $MessageSubject, $scr

$SMTPClient = New-Object System.Net.Mail.SMTPClient $SendingServer

$SMTPClient.Send($SMTPMessage)

You can see that the SMTP Whitelist text file contents are piped into a $string variable, and this $string variable is used as the Message Body.  All references to the attachment are dropped.   The previous lines of code for the queries remain the same.

The second variant excludes any Mail Groups that have the Require Sender is Authenticated setting enabled ($true).  This is a default setting for Exchange 2010 Mail Groups, and needs removing if you wish the Mail Group to receive internet email to the SMTP address assigned to that Mail Group.   You may wish to optimize your SMTP Whitelist to not include the SMTP addresses for Mail Groups that are set to Require Sender Authentication.   Do achieve this you need to modify the DSQUERY line used to generate the SMTP addresses for the Mail Groups:

dsquery * -filter “(&(objectCategory=group)(objectClass=group)(mail=*@contuso.com)(!msExchRequireAuthToSendTo=TRUE))” -attr mail -limit 0 >smtp_groups.txt

Note the inclusion of the additional LDAP Filter,  !msExchRequireAuthToSendTo=TRUE .  The use of the exclamation mark at the front performs a reverse query, so will return all Mail Groups who do not have the msExchRequireAuthToSendTo=TRUE AD attribute set.   You can cross check the Mail Group AD objects in the AD Attribute Editor, or ADSIEdit, to see how this msExchRequireAuthToSendTo value is set.   The reverse query trickery is required, as I was unable to find a way to do a successful DSQUERY against the <not set> value, or null.    This works a treat, and will ensure only Mail Groups that are set to receive external internet email are included in your final SMTP Whitelist.

Domino to Exchange 2010 Email Migration vs Quest Mail Group Provisioning, Mail Group Ownership, and OWA ECP

Posted on by
5

When migrating from Domino to Exchange 2010 using the Quest Notes Migrator to Exchange tool, you can make use of Quest’s  Group Provisioning function.    This allows Distribution Lists in Domino to be migrated to Exchange 2010, and also allows for membership synchronization (1-way only from Domino to Exchange).  Read Quest’s detailed product documentation for full details of this feature.

Note:  “Distribution List” and “Group” are interchangeable for this blog, in order to cover the same subject across both Domino and Exchange.

This function needs to be carefully managed during the email migration project, to minimize business impact.

Firstly, decide which Mail Group types you want to provision in Exchange 2010.  In Domino there are three Mail Group types:

  • Mail Only
  • Mail & Security
  • Security

Of these types I recommend provisioning Mail Only and Mail & Security in Exchange 2010.   Each subset should then be placed into their own Quest Collections, prior to any provisioning.

Then, the Mail Only Groups can be migrated (provisioned) across into mail-enabled Universal Distribution Groups (UDG) in Exchange 2010, and the Mail & Security Groups can be migrated across into mail-enabled Universal Security Groups (USG) in Exchange 2010.  Ensure you tick the option to synchronize the Group membership, as this will be useful later.

Quest Notes Migrator to Exchange - Group Provisioning

This gives the option of using the Mail & Security Groups in Exchange as Access Control Lists if required later – this is a likely scenario, as this could have been how they were utilized within Domino, maybe for Domino Application access.

The Security Groups in Domino should not need to be provisioned in Exchange 2010 unless you have been specifically requested to provision them in Active Directory for a non-messaging purpose.  If you have been asked to do this, a recommended way of provisioning them is to place them in their own Quest Collection, and then use Quest to provision them as mail-enabled Universal Security Groups into their own dedicated Active Directory Organizational Unit, as a one-off exercise.   Then, go into EMC (Exchange Management Console), and block select them, then right-click and use the Disable option to remove the mail attributes from the selected Groups.   This will result in them remaining as “non-mail enabled” Universal Security Groups, which you can pass across to the Active Directory team to manage on going.

Quest Notes Migrator to Exchange can then be used to run the Group Provisioning option against any of your Collections to synchronize the Group membership.  This is only in one direction, from Domino to Exchange, and is very useful during the co-existence period, as it is likely that Domino users would have been granted the Editor right to manage the Group membership.

When migrating Groups using the Quest Notes Migrator to Exchange tool, an attempt is made to grant the Domino Owner, and Domino Managers, of each Group onto the equivalent within the Exchange 2010 instance of the Group.

Domino Mail Group Settings

However, the two email platforms are different and this is not done in a consistent manner, which can cause issues.

Within Domino, the Group permissions are split into two areas:

  • Owner:  people listed here can edit Group membership, and grant people rights to Manage the Group (allows them to change Group membership).   Entries here can be for individuals and/or other Groups.
  • Managers: people listed here can edit Group membership. Entries here can be for individuals and/or other Groups.

Within Exchange 2010, the Group permissions are split into two areas also:

  • Owner: only one person can listed here, via the Managed By tab, and Owner field in the Active Directory properties on the Group.

    Active Directory Managed By & Owner Setting

    This is purely a text label, and does not give the person rights to change anything within the Group.  However, the person’s name does appear within the Group properties when viewed from within Outlook 2010

  • Managed by:  set via Exchange Management Console, Group properties, multiple individual people can be listed here, and they have the rights to edit the Group membership.

    EMC - Group Information Tab

    However, any names listed here are not visible in the Group properties when viewed from within Outlook 2010.

Microsoft offers the ECP feature (Exchange Control Panel), via OWA 2010,  which combined with Roles Base Access Control, offers a real alternative to managing Groups. See the Microsoft Technet article on this topic: TechNet Link.   However, when migrating from Domino, this feature does not offer a “like for like” setup, which is always a more immediate priority during an email migration project – in my experience.

Back to the Quest migration of Groups…

When migrating a Domino Group to Exchange 2010, Quest tries to place the Domino Owner in as the Active Directory Owner.     Microsoft allows for a Group name to be used as the Active Directory Owner, but Exchange 2010 does not accept this.   This is a real problem, as it will prevent any future changes being saved to the Group from the Exchange Management Console property page for that Group.  You need to go into Active Directory and “Clear” the Group name from the Owner field in the Managed by tab.

Active Directory Managed By & Owner Setting

Then you can make the changes you need within EMC.   However, if you re-run the Quest Notes Migrator to Exchange provisioning step for that Group to sync the membership, it then replaces the Active Directory Owner with the Domino value again.  This is a real problem, and a real nuisance for an email migration with a co-existence period.

The issue can be avoided by either:

  • Editing the Domino Owner field to show only an individual, not a Group.   This allows you to continue synchronizing the Groups during co-existence.
  • Stop synchronizing the Groups via Quest, and start using only the Exchange Groups.   Then clear the AD Manager field for any required AD Groups, as the value will not get re-populated by Quest, as you have stopped using it.   This may not be a viable option as typically co-existence can last for an extended period, during which the Quest Group sync feature is very useful.
  • Migrate the Mail Groups last.   You could opt to leave the Mail Groups to be represented by Mail Contacts in Exchange 2010 during co-existence.   That means that the Mail Groups only exist in Domino for this period. Any users wishing to modify any Mail Groups during co-existence can be told to do this via their legacy Lotus Notes client.  Not ideal, but is a workable solution.   Then, after the user migrations are all complete, the Mail Groups are all migrated, en masse, across to Exchange 2010, the necessary user rights are applied on each one (manually if needed), and from that point onwards, the Exchange 2010 Mail Groups are the primary instances.  The Domino Mail Groups can then be hidden from the Notes Address Book, or disabled somehow.

In order to grant the editor rights to each Exchange Group, you will need to add the mailbox names into the Group Information tab within the Group properties, in Exchange Management Console.

EMC - Group Information Tab

This feature also presents a restriction, in that only mailboxes can be added here, not Groups.  So if you were copying the ACLs over from Domino you will have to look-up the Group members, and then add them in individually.   Another nuisance !

It is common, in Domino, to have an Admins Group (name can vary) assigned as the Owner of all of the Domino Groups.   If that is the case, and these Groups are the ones that keep getting populated into the AD Manager field, then there is a trick to work around it.   What you can do, is to delete the Exchange instance of the Admins Domino Group, and create a new Mail Contact of the same name, with the same SMTP addresses assigned to it. Eg:  admins@contuso.com . This will prevent Quest from re-creating the Domino Group in Exchange.  But more importantly, Quest will then be unable to populate the Manager field of any provisioned Groups in AD with the Admin Group, as it will be unable to locate it (it uses the SMTP address to find it) – because the lookup will only find the new Mail Contact you created, which cannot be used in the Manager field.  Quest will then pick the first alphabetic name from the list of names from the list of Administrators of the Domino Group, which would typically be a normal business user mailbox – which is a perfect outcome.  This means that the Quest Group sync process can be run throughout co-existence without issue.

Finally, to overcome the problem of Outlook 2010 users not knowing who has access rights to manage the Group membership, I advise that the Notes field under the Group Information tab (in EMC) is used to add a text description of who has these rights.  This information is clearly visible to any Outlook 2010 users who view the properties of the Group entry in the Global Address Book.

 

EMC - Mail Group Properties & Notes field

The above information should be sufficient to allow you to provision any required Domino Groups in Exchange 2010, ready for co-existence, which function the same way as in Domino, with regards to membership, and allowing the correct people to manage the Group membership.   This will also allow you to avoid being forced to implement the Exchange Control Panel feature via OWA across the whole business, as this will more than likely take an amount of time to get agreement on, test, and implement.  It is easier to put in place the same functional setup as was present in Domino, especially for co-existence, as it is one less area for users to complain about !

This is a complex topic (!) but am keen to make you aware of some of of the pitfalls, and work-arounds, in commonly neglected areas during an email migration off Domino onto Exchange 2010.   A big factor is how tolerant the business is to change, and whether you need to look at the migration period in this level of detail or not.   Personally, I always try and keep the end-user happy during an email migration wherever possible.

Please let me know if you have any questions or comments on this blog.