IBM Lotus Notes & Domino 8 VS Microsoft Exchange & Outlook 2007

Feature	IBM Lotus Domino VS MS Exchange 2007
Company	IBM	Microsoft
Supported Platform	Support Windows 2003, IBM AIX, Linux (on Intel), Linux (System Z), IBM i5/OS, IBM z/OS, and Sun Solaris.	Only Support 64-bit Windows Platform in production.
IBM Lotus Domino 8 is the definite winner when it come to the number of platform it support. Exchange 2007 support only Windows 2003 64-bit version which limit a lot of organizations who is running at different platform than Windows. Even if you are running windows 2003 you will be forced to buy window 2003 64-bit edition, as the 32-bit addition is not supported in production any more.
Complementary Products	Sometime instant messaging, IBM WebSphere Portal, Tivoli Directory Integrator, Websphere Application Server are only examples of the IBM Complementary products IBM Lotus Domino Customers are applicable for.	Microsoft does not offer any specific complementary product with Exchange 2007, but offer extra paid products that can integrate with Exchange 2007.
IBM Lotus Domino 8 is the definite winner when it come to the number of Complementary products. Microsoft will charge you an arm and leg to get features equivalent to the free complementary products IBM Lotus Domino 8 customers applicable for.
Virtualization Support	Hardware & Software virtualization support	Does not support Virtualization
* What is Microsoft idea of not supporting Exchange 2007 in any type of virtualization at the moment and not even releasing a date when it will be supported. Yes, it might work but won't be supported by Microsoft. * In the other hand IBM support Lotus Domino in both hardware virtualization (Power Series) & Software Virtualization (VMware ) * As Virtualization becoming to be the market trend at the moment due to the fact of it saving money, space, hardware, and easy provisioning it seems a real catch when Microsoft does not support it when exchange 2007 requires a lot more roles and more hardware which could been virtualized and allow good saving on the hardware cost.
Upgradeability & Integration: In Place Upgrade from earlier versions Integrate with earlier versions Earlier versions Application Support	Yes Yes Yes	No Yes, but not 5.5 No
* IBM Lotus Domino 8 can do in place upgrade of earlier versions of Domino, where Exchange 2007 can only do a complicated migration of earlier versions. It even requite upgrading Exchange 5.5 to 2000/2003 prior to migration. * IBM Lotus Domino 8 can integrate with earlier versions of Domino, MS Exchange 2007 can do the same with Exchange 2000/2003, but not with Exchange 5.5. * Applications written to work with earlier versions of Lotus will most likely work with Lotus Domino 8, where applications written for earlier versions of Exchange will more than likely not work with Exchange 2007 which is a huge waste of investment.
Solution Type	Complete Solution	Messaging only Solution
* IBM Lotus Domino 8 offers e-mail, Contacts, Calendaring, team spaces, forums, Integrated IM & Presences awareness, and development tools. * MS Exchange 2007 only offer a messaging solution and if you need any further functionality you have to pay for an extra product.
Composite Applications:	Yes	No
* IBM Lotus Domino 8 has NSF-based composite application that includes both NSF and Eclipse components that offers an easy way to make applications that integrate into Lotus Notes without extensive coding. In the other hand, Microsoft does not offer any equivalent to that.
Clustering Type:	Application Level	OS Level
* IBM Lotus Domino 8 Cluster is on the application level which make it more flexible and give a higher availability than Microsoft Exchange 2007 Cluster which is OS Level cluster and highly dependant on the OS Clustering capability of windows 2003.
Replication Reliability:	High	Low
* IBM Lotus Domino has implemented replication for ages to be one of the most reliable and efficient replication methods available. * MS Exchange 2007 is the first Exchange version to support replication. The replication was not reliable in the RTM release and got a bit better with SP1 but still not the best. In addition, Exchange 2007 replication is not efficient and requires a large amount of dedicated bandwidth which can be expensive.
Software Release Approach:	Fully Tested - Ready for Production	Half-Raw till SP1
* IBM has release Lotus Domino 8 as a solid product fully tested and ready for production, but was a bit late to market. * Microsoft as usual early to market with half raw product at the RTM version of Exchange 2007 with many bugs and features missing few examples: - Public folders Management GUI - Replication was not working unless implemented directly by Microsoft with some secret hotfixes. - Single Copy Cluster was not working unless installed with certain hotfixes in certain orders which was not mentioned any where on Microsoft website and not applying the fixes will make the cluster resources jump from a node to the other. Note: these were few of the issues Microsoft fixed with SP1, but even SP1 had its own issues that Microsoft admit in the release note of SP1 and the installation of SP1 has not been smooth for many customers.
Maintenance:	Install & Forget	Time-Consuming
* Microsoft as usual has kept their product maintenance quite time-consuming doing updates for exchange, operating system fixing failures and recovering data stores. It seems they are trying to help administrators look busy to keep their jobs. * IBM has kept again the Install & Forget approach. After Domino has been installed you only need to visit the box if you need to add or enable a feature. It does not mean administrators will lose their job, but will have an easier life.
Microsoft Office Integration	Yes, but require a free connector	Out of the Box
* As Microsoft Office is a Microsoft product which as expected integrate better with Microsoft Exchange 2007 and without the need for any extra packages, though IBM has released a connector for Lotus Domino that will provide a quite good integration with office. In the other hand, IBM has their own mail Client Lotus Notes which is a great one.
Security:	offers advance security features including: local encryption, digital signatures, Server & user defined level SPAM control, and granular access control.	Although Microsoft has put a lot of effort into building some spam protection and enhancing their security features in Exchange 2007 they still struggle as usual with many security leaks, virus propagation and security holes.
Encryption:	up to 4096 bit RSA encryption keys and 128 bit symmetric keys	offer some type of encryption, but optional.
Costs: Initial License costs for only messaging system (non redundant): Initial License costs for only messaging system (redundant): Initial License costs for full solution: Full Solution including hardware, licenses, and software cost. Total Cost of Ownership (TCO)	A bit more expensive Cheaper Cheaper Cheaper Lower	A bit cheaper More Expensive More Expensive More Expensive Higher
Exchange 2007 get to be cheaper only if you calculate the initial licenses for non redundant setup. In all the other calculation and TCO Exchange 2007 will be in a loss situation. Exchange 2007 require newer 64-bit hardware and more servers (at least 6 server in case of redundancy) where Lotus Domino can reach full redundancy with two servers only, this is due to the new roles Exchange 2007 came up with. More servers means more licenses and clustering with Exchange require windows enterprise licenses which not required with Lotus Domino. All this give Domino an initial setup advantage when you look at the full setup cost. In addition, if your setup require features like forums, portal, and instant messaging you will have to pay for an extra three separate products with Exchange where all of these are integrated into Domino server for free. All that Make Domino the TCO winner.

How to rebuild the domain SYSVOL replica set across enterprise environments

This section describes how to rebuild the domain SYSVOL replica set across enterprise environments.

Summary of the steps

The following is a summarized list of steps that are performed in a hub or branch restart:

1. Stop the FRS on all domain controllers in the domain.
2. Move all files and folders that should reside in the SYSVOL tree to a temporary folder on the reference domain controller. The temporary folder should be located on the same partition the SYSVOL tree is located.
   
   Note When you move files within a partitions, the files are not altered. Therefore, they retain their original security settings. Files or Folders that are moved partitions or copied within or between partitions inherit the security of the destination parent directory. Therefore, any custom delegations of GPO management may be lost as a result. Additionally, the access control list (ACL) on the SYSVOL part of the Group Policy object is set to inherit permissions from the parent folder. Therefore, you may receive the following error message when you open a GPO by using GPMC:

The Permissions for This GPO in the SYSVOL Folder Are Inconsistent with Those in Active Directory

If you have permissions to modify security on the GPO, click OK when you receive this error message. This action modifies the ACLs on the Sysvol part of the Group Policy object and makes them consistent with the ACLs on the Active Directory component. In this case, Group Policy removes the inheritance attribute in the Sysvol folder.

3. Verify junction points and required folders on each domain controller in the domain.
4. Restart the FRS on the reference domain controller with the D4 registry entry set.
5. Restart the FRS on all other domain controllers in the domain with the D2 registry entry set.
6. On the reference domain controller, move all files and folders to the root folder of the replica set. By default, this folder is the C:\Windows\Sysvol\Domain folder.
7. Monitor the consistency of files and folders for all domain controllers in the domain.

Note If a member of any replica set has been restarted with the Burflags registry entry set to D4, restart the FRS on all other members of the replica set with the Burflags registry entry set to D2. This configuration prevents morphed folders.

When the Burflags registry entry is set to D2 or to D4, and the FRS is restarted, the originator GUID (OrigGUID) changes. If you want to track the source of a specific activity, you can run the File Replication Service Diagnostics Tool (FRSDiag) to obtain GUID2Name before you set the Burflags registry entry.

Detailed list of the steps

The following is a detailed list of steps that are performed in a hub or branch restart:

1. On all domain controllers in the domain, stop the FRS, and then set the service startup type value for the FRS to Disabled.
2. On a single domain controller, configure the SYSVOL replica set to be authoritative. This reference domain controller will contain the authoritative copy of the SYSVOL tree for all other members of the replica set. For example, other domain controllers in the domain will directly or transitively replicate from this reference domain controller.
   
   Choose the reference domain controller based on connectivity and physical server resources. This domain controller will be known as the "reference domain controller" in all subsequent steps.
   
   To configure the SYSVOL replica set to be authoritative, follow these steps:

a. Click Start, click Run, type regedit, and then click OK.

b. Locate and then click the BurFlags entry under the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID

GUID is the GUID of the domain system volume replica set that is shown in the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\GUID

c. Right-click BurFlags, and then click Modify.

d. Type D4 in the Value Data field (HexaDecimal), and then click OK.

On all domain controllers in the domain, verify that the file structure and junction points are correct. To do this, follow these steps:

. Verify that the following folders exist in the SYSVOL tree :

\SYSVOL
\SYSVOL\domain
\SYSVOL\staging\domain
\SYSVOL\staging areas
\SYSVOL\domain\Policies
\SYSVOL\domain\scripts
\SYSVOL\SYSVOL

a. Verify that the following reparse points exist:

\SYSVOL\SYSVOL\ DNS Domain Name
This reparse point must be linked to the \SYSVOL\domain folder.

\SYSVOL\staging areas\DNS Domain Name
This reparse point must be linked to the \SYSVOL\staging\domain folder.

The default path for the SYSVOL tree is under the \WINDOWS or \WINNT folder on the partition where the operating system is installed. However, the SYSVOL tree may be installed on any partition that is formatted by using the NTFS file system.

Verify that each domain controller in the domain has all the required folders and that the reparse points exists. Re-create any missing folders as needed. Do not use Windows Explorer to move or copy contents of the SYSVOL tree, or the reparse points may be damaged.

The SYSVOL tree contains reparse points to other folders in the SYSVOL tree. These reparse points are in the NTFS file system. Think of a reparse point as a source folder that maps or points to a destination folder when the source folder is accessed. The contents of the reparsed folders appear as mirror images of each other.

The following two reparse points for a SYSVOL tree are installed in the C:\WINNT\SYSVOL folder:

• C:\WINNT\SYSVOL\SYSVOL\DNS Domain Name.
  This reparse point is linked to the C:\WINNT\SYSVOL\domain folder.
• C:\WINNT\SYSVOL\staging areas\DNS Domain Name
  This reparse point is linked to C:\WINNT\SYSVOL\staging\domain folder.

On each domain controller in the domain, follow these steps:

1. Click Start, click Run, type cmd, and then click OK.
2. Type net start ntfrs to start the File Replication service.
3. Type ntfrsutl ds |findstr /i "root stage", and then press ENTER. The NTFRSUTIL command returns the current root directory for the SYSVOL replica set that is referred to as the “replica set root” and the staging folder. For example, this command returns:

Root: C:\WINNT\SYSVOL\domain
Stage: C:\WINNT\SYSVOL\staging\domain

4. Type Linkd %systemroot%\SYSVOL\SYSVOL\ DNS Domain name, and then press ENTER. The LINKD command returns the following:

Source DNS Domain Name is linked to %systemroot%\SYSVOL\domain

5. Type linkd "%systemroot%\SYSVOL\staging areas\DNS Domain Name", and then press ENTER. This command returns the following:

Source DNS Domain Name is linked to %systemroot%\SYSVOL\Staging\domain

Note The path that is reported by the LINKD command varies depending on the location of the SYSVOL\SYSVOL\DNS Domain Name folder. If the SYSVOL folder is in the default location in the %systemroot%\SYSVOL folder, use the commands that are listed. Otherwise, type the actual path of the SYSVOL folders.

For example, if the NTFRSUTL and LINKD commands are run on a domain controller in the contoso.com domain, and the SYSVOL folder is in the C:\Windows\SYSVOL folder, the command syntax and results for the SYSVOL and Staging folders will appear similar to the following:

C:\>ntfrsutl ds |findstr /i "root stage"

Root: C:\windows\sysvol\domain

Stage: C:\windows\sysvol\staging\domain

C:\>Linkd %systemroot%\SYSVOL\SYSVOL\Contoso.com

Source domain.com is linked to

C:\WINDOWS\SYSVOL\domain

C:\>linkd “%systemroot%\SYSVOL\staging areas>\Contoso.com

Source domain.com is linked to

C:\WINDOWS\SYSVOL\staging\domain

To re-create the junction points if the LINKD command reports missing or invalid junction points, follow these steps:

1. Type linkd C:\WINNT\SYSVOL\sysvol\DNS_Domain_Name Source, where Source is the root path that is determined by using the NTFRSUTL command.
2. Type C:\linkd "C:\WINNT\SYSVOL\staging areas\DNS_Domain_Name " Source, where Source is the stage path that is determined by using the NTFRSUTL command.

For more information about creating junction points, click the following article number to view the article in the Microsoft Knowledge Base:

6. On all domain controllers in the domain, verify that enough staging space is available. The ratio of staging area size to data set size depends upon a range of factors. For more information, click the following article number to view the article in the Microsoft Knowledge Base:

To determine the size of the replica set root, right-click the replica set root that uses the Winnt\SYSVOL\domain folder in Windows Explorer, and then click Properties.

To adjust the staging folder size, follow these steps:

a. Click Start, click Run, type regedit, and then click OK.

b. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters

c. Right-click Staging Space Limit in KB, and then click Modify.

d. Click decimal, type the size of the staging folder in kilobytes, and then click OK.

e. Quit Registry Editor.

On the reference domain controller, build a good set of policies and scripts, and then put them in a temporary folder outside the SYSVOL replica set folders on the FRS reference domain controller.

To complete this step, examine Active Directory to determine the group policies that are still used and that contain orphaned data. Policy information is located in the Group Policies container. To view this container, follow these steps:

. Start Active Directory Users and Computers.

a. On the View menu, click Advanced Features if it is not already selected.

b. Expand the domain container, expand the System container, and then expand the Policies container.

In the right pane of Active Directory Users and Computers, all the Group Policy objects (GPOs) in Active Directory are listed. There should be a one-to-one mapping between valid GPOs in Active Directory with Group Policy folders in the SYSVOL tree.

§ If the SYSVOL folder contains a folder name that has a GUID that is not listed in Active Directory, the file system contains an orphaned GPO, and you can safely delete the folder from the file system.

§ If Active Directory contains a Group Policy GUID that does not map to a GUID in the SYSVOL\domain\policies folder on any domain controller in the domain, you can safely delete that policy setting from Active Directory.

Note If any domain controller that is participating in the domain has a newer version of a Group Policy in its local SYSVOL tree, make sure that it is copied to a temporary location on the reference domain controller.

c. On the reference domain controller, delete any files or folders that are in the FRS replica set root or in the replica set stage folders.

For default SYSVOL replica sets, delete files and folders under the following two folders:

C:\WINNT\SYSVOL\domain
C:\WINNT\SYSVOL\staging\domain

Note Do not delete the folders themselves.

d. On the reference domain controller, move the policies and scripts folders and the folder contents from the temporary location that you used in step c to the FRS replica set root folder. For the SYSVOL folder, the default location for the replica set root is the following folder:

C:\WINNT\SYSVOL\domain

e. On all domain controllers except the reference domain controller, configure the FRS to be non-authoritative. To do this, follow these steps:

1. Click Start, click Run, type regedit, and then click OK.

2. Locate and then click the BurFlags entry under the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID

GUID is the GUID of the domain system volume replica set that is shown in the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\GUID

3. On the Edit menu, point to New, and then click DWORD Value.

4. Type D2 for the name of the DWORD, and then press ENTER.

Note For domain controllers that are not participating in Distributed File System (DFS) replication, set the DWORD to D2 in the following registry subkey for bulk modifications:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process atStartup\BurFlags

f. Quit Registry Editor.

The FRS is instructed to reinitialize its database and to overwrite the contents of the SYSVOL tree with data from an upstream partner.

In large sites, we recommend that you use a staggered approach to rebuilding the SYSVOL tree. This approach helps avoid overloading a single domain controller or causing the FRS to source its contents from a domain controller that has not completed its own re-sourcing of the system volume. This process involves setting the Burflags registry entry to D2 on all hub site domain controllers before proceeding to branch office or to satellite sites.

Use the Replica Set Parent registry entry to specify a source domain controller for the D2 setting:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\SYSVOL Seeding\DOMAIN SYSTEM VOLUME (SYSVOL SHARE)

o Replica Set Parent
Type: REG_SZ
Value: The source domain controller

Note If this registry entry does not exist, you must create it.

We recommend that a single domain controller not become the source for more than 10 to 15 domain controllers at the same time. If you must source more than 15 domain controllers off a single source, start the FRS on only 15 downstream partners of any particular source domain controller, and then wait for them to complete sourcing the SYSVOL tree before the FRS service is started on the next group of 15 computers.

Notes

o We do not recommend that more than 15 domain controllers source their contents off of a single domain controller at the same time.

o Incoming replication depends on a schedule that is defined on the relevant site link or on the connection object that is used by the destination domain controller that allows replication. If the replication schedule is disabled, incoming replication will be delayed.

o If the “Replica set parent” registry entry is used, the FRS will source data upon restart of the service, independent of the whether replication is enabled or disabled on the day or the hour that the service restart occurred. After the initial source is complete, all additional replication will be based on connection schedules. If the registry entry is not used, the FRS will initiate replication based on the schedule that is defined on the relevant site link or connection object.

On all domain controllers in the domain except the reference domain controller, delete any files or folders under the FRS replica set root and the replica set stage directories. For example, for default SYSVOL replica sets, delete files and folders in the following two locations:

C:\WINNT\SYSVOL\domain
C:\WINNT\SYSVOL\staging\domain

Note Do not delete the folders themselves.

This step enables faster replication of the SYSVOL tree for the given source. This step eliminates the need for the FRS server to move the existing contents before replicating the new data. This step is not required but it is recommended.

On all domain controllers in the hub site, except the reference domain controller, restart FRS, and then verify that SYSVOL and NETLOGON are shared.

Note The service startup type for the FRS should be set to Automatic.

On all non-reference domain controllers in the branch sites, start the FRS service and verify that SYSVOL and NETLOGON are shared.

How to temporarily stabilize the domain SYSVOL tree

1. Stop FRS on all domain controllers in the domain and set the service to Disabled.
2. Manually copy the full set of policies to the following folder on each domain controller:

\SYSVOL\SYSVOL\dns domain name\policies

Typically, the following two policies are required for authentication:

• Default Domain Controllers Policy {6AC1786C-016F-11D2-945F-00C04fB984F9}
• Default Domain Policy {31B2F340-016D-11D2-945F-00C04FB984F9}

Note You may have to copy additional policies depending on Group Policy requirements for the environment.

3. Manually copy all necessary scripts to the following folder:

\SYSVOL\SYSVOL\DNS Domain name\scripts