As part of the post installation tasks, the first two immediate steps include verifying the installation and then registering a product key on the server.
The former step requires a little experience on installing Exchange servers. The primary step recommended by Microsoft is to view the Exchange Setup Logs which will be in a folder of similar name on the installation drive. These logs should reveal any problems encountered during the installation. With my failed installation attempt, I can tell you there are other indicators to consider. The System and Application event logs and the services should be examined. The Exchange Management Console (EMC) and Exchange PowerShell should be open as well. Both the EMC and Powershell hung with my installation. If the EMC opens correctly, poking around the gui and running PS commandlets such as get-exchangeserver develop a warm fuzzy that things were placed in the correct order.
The product key relates very closely to your choice of editions. The available editions of Exchange 2010 are Trial, Standard and Enterprise. The bits for each edition are the same and the product key enables features of each edition. The trial edition is the installation with out a product key. This gives you 120 days of testing out the equivalent of a standard edition. Registering a product key will upgrade it to the qualified edition of that key. The standard edition has a limit of 5 mailbox databases while the enterprise edition goes up to 100 databases. All other functionality is available in both editions. Although the product key enables the edition, you cannot revert to a downgraded version such as switching the enterprise edition to a standard edition.
When considering which edition you would like, you also have to consider the client access license (CAL). The Exchange CAL comes in two flavors as well, standard and enterprise. The enterprise CAL is an add-on to the standard CAL. You purchase enterprise CAL on top of the standard CAL to get additional compliance functionality such as retention policies, archiving and mailbox search capabilities. You can have a mix of CALs as well. The Exchange server doesn’t track CALs so these functionalities are not disabled if you have only standard CALs. Remember the use of these features based on CALs is on the honor system and the law can stiff your organization serious buckage in a fine for each licensing violation.
On a side note, additional CALs are required for using Exchange CALs. The Windows Server CAL is mandatory. The Windows Information Rights Management (IRM) CAL is required for implementing rights management on emails.
To enter the product key into the installation, the EMC offers a gui based method which is built on the PowerShell commands. So for the sake of brevity, we’ll do it with the PS method:
Set-ExchangeServer -Identity Exch2010 -ProductKey 12345-abcde-12345-abcde-12345
Thursday, November 12, 2009
Tuesday, November 10, 2009
Exchange 2010 Installation
On the day of the RTM release of Exchange 2010, I successfully installed the RC version on a virtual machine. My delay was not due its difficulty. I ran into those virtual machine foibles such as running out of disk space and accidental shut downs by sons who want to get on www.lego.com.
It would also have speeded up if I found a comprehensive list of the software prereqs. It may be out there but I decided to just run the setup and see what kicked back. So here is what I found:
- Windows Server 2008 SP2. (See note below)
- .net Framework. This is a feature within Windows Server 2008.
- Powershell 2.0. This was mentioned in my previous blog. A hyperlink concerning this is listed on the Setup page.
- Internet Information Service (IIS). This is role in Windows Server 2008.
- World Wide Web service (W3SVC), a sub role of IIS.
- Additional sub roles of W3SVC:
IIS 7 Basic Authentication
IIS 7 Windows Authentication
IIS 7 Digest Authentication
IIS 7 .NET Extensibility
IIS 7 Dynamic Content Compression
IIS 7 Static Content Compression
IIS 7 .NET Extensibility
IIS 6 Metabase Compatibility
IIS 6 Management Console
Web Server (IIS) Tools
- HTTP Activation (under .NET Framework 3.0 Features\WCF Activation\HTTP Activation). This enables additional check boxes under W3SVC.
- Windows Process Activation Service Process Model (I couldn’t figure out where the check box was for this. It was checked through one of the above roles or features.)
- 2007 Office System Converter: Microsoft Filter Pack
During the system check, even after getting the above items running, there were these notifications:
Warning:
If Microsoft Outlook 2003 is in use, you should replicate the free/busy folder on this server to every other free/busy server in the organization. This step should be performed once Setup completes.
Error:
The start mode for the Net.Tcp Port Sharing service must be set to Automatic before Setup can continue.
The Net.TCP Port Shareing service was disabled by default.
The setup process is straight forward. It queried for only a few items before running through the installation:
- CAS server name. This is the intended FQDN for a CAS role that will receive Internet email. I entered the current organization’s “mail.shogun.local” name which is currently hosted by the Exchange 2k3 server.
- The Exchange 2003 server for the Routing Group Connector between the two organizations.
- Participation in the error reporting process.
- Type of Installation. This is the choice between typical and custom. The typical install includes the Mailbox, Hub Transport and Client Access Service roles. Custom allows you to pick and choose. I chose Typical.
Thus with all of the needed information is ran without error, specifically on the final attempt.
Now, here are some steps I learned in cleaning up the botched installation. It failed late in the game thus there was still information about it in Active Directory. Since it was all in Active Directory, I resolved to use ADSI Edit to delete some of the objects. I also used PowerShell to reconfigure the organization to rid it of the failed installation:
- Deleted public and mailbox databases from the Databases node. One big change in Exchange 2010 is the separation of databases from their servers. So there is a new node listing all of the databases.
- Delete the server from the server node.
- Created a new routing group connector between the new Exchange server and the Exchange 2003 server. I used the new-routinggroupconnector command for this. Constructing the command was pretty simple since an example in the get-help new-routinggroupconnector -full output was exactly what I needed.
- Deleted the original routing group connector with the remove-routinggroupconnector command in Powershell.
- Deleted the instance of the original routing group connector in the Exchange 2003’s portion of Active Directory using ADSI Edit.
After this, it appeared that the botch installation was no more to be remembered. I’ll add more steps if I find additional remnants.
Note: After posting this blog, I found the Technet page concerning the prereqs. I know I should be looking for this before hand, but I was just playing around with the install for training purposes. http://technet.microsoft.com/en-us/library/bb691354.aspx
Here are some additional tidbits to be aware of...
It would also have speeded up if I found a comprehensive list of the software prereqs. It may be out there but I decided to just run the setup and see what kicked back. So here is what I found:
- Windows Server 2008 SP2. (See note below)
- .net Framework. This is a feature within Windows Server 2008.
- Powershell 2.0. This was mentioned in my previous blog. A hyperlink concerning this is listed on the Setup page.
- Internet Information Service (IIS). This is role in Windows Server 2008.
- World Wide Web service (W3SVC), a sub role of IIS.
- Additional sub roles of W3SVC:
IIS 7 Basic Authentication
IIS 7 Windows Authentication
IIS 7 Digest Authentication
IIS 7 .NET Extensibility
IIS 7 Dynamic Content Compression
IIS 7 Static Content Compression
IIS 7 .NET Extensibility
IIS 6 Metabase Compatibility
IIS 6 Management Console
Web Server (IIS) Tools
- HTTP Activation (under .NET Framework 3.0 Features\WCF Activation\HTTP Activation). This enables additional check boxes under W3SVC.
- Windows Process Activation Service Process Model (I couldn’t figure out where the check box was for this. It was checked through one of the above roles or features.)
- 2007 Office System Converter: Microsoft Filter Pack
During the system check, even after getting the above items running, there were these notifications:
Warning:
If Microsoft Outlook 2003 is in use, you should replicate the free/busy folder on this server to every other free/busy server in the organization. This step should be performed once Setup completes.
Error:
The start mode for the Net.Tcp Port Sharing service must be set to Automatic before Setup can continue.
The Net.TCP Port Shareing service was disabled by default.
The setup process is straight forward. It queried for only a few items before running through the installation:
- CAS server name. This is the intended FQDN for a CAS role that will receive Internet email. I entered the current organization’s “mail.shogun.local” name which is currently hosted by the Exchange 2k3 server.
- The Exchange 2003 server for the Routing Group Connector between the two organizations.
- Participation in the error reporting process.
- Type of Installation. This is the choice between typical and custom. The typical install includes the Mailbox, Hub Transport and Client Access Service roles. Custom allows you to pick and choose. I chose Typical.
Thus with all of the needed information is ran without error, specifically on the final attempt.
Now, here are some steps I learned in cleaning up the botched installation. It failed late in the game thus there was still information about it in Active Directory. Since it was all in Active Directory, I resolved to use ADSI Edit to delete some of the objects. I also used PowerShell to reconfigure the organization to rid it of the failed installation:
- Deleted public and mailbox databases from the Databases node. One big change in Exchange 2010 is the separation of databases from their servers. So there is a new node listing all of the databases.
- Delete the server from the server node.
- Created a new routing group connector between the new Exchange server and the Exchange 2003 server. I used the new-routinggroupconnector command for this. Constructing the command was pretty simple since an example in the get-help new-routinggroupconnector -full output was exactly what I needed.
- Deleted the original routing group connector with the remove-routinggroupconnector command in Powershell.
- Deleted the instance of the original routing group connector in the Exchange 2003’s portion of Active Directory using ADSI Edit.
After this, it appeared that the botch installation was no more to be remembered. I’ll add more steps if I find additional remnants.
Note: After posting this blog, I found the Technet page concerning the prereqs. I know I should be looking for this before hand, but I was just playing around with the install for training purposes. http://technet.microsoft.com/en-us/library/bb691354.aspx
Here are some additional tidbits to be aware of...
- If you want to use the high availability feature of Exchange 2010, you will need W2k8 Enterprise Edition.
- .net Framework 3.5 SP1 is required. At some point, it was installed on my server however, I didn't specifically launch an installation of it.
- The MS Office Filter Pack is required on HT or MB roles.
- To install all of the required roles and features on a W2k8 server, Exchange 2010 offers a scripts folder with .xml files which can be ran with the ServerManagerCMD command. You can select a script based on the planned Exchange roles.
- To install all of the required roles and features on a W2k8 R2 server, the above web site has PowerShell commands to install them. You can copy and paste it to the Exchange server.
Tuesday, November 3, 2009
Exchange 2010 Preparing the Environment
In my last blog, I laid out the basic steps of performing a migration to Exchange 2010. Since the most probable customers choosing to migrate will have Exchange Server 2003, the direction of the migration will be based on the following environment:
- A single domain Windows Server 2003 Active Directory environment with the highest domain and forest functional levels.
- A single Exchange Server 2003 SP2 server. This will host OWA with forms based authentication. Thus, it has SSL enabled with the CNAME of mail.shogun.local. (Shogun is my test lab domain name. Long story.)
- A workstation running XP and Outlook 2003. Using a latter version will not have any impact on the migration. There are features of Exchange 2010 that will not be available using Outlook 2003. We’ll upgrade this down the road to play with those.
In addition to these operating systems, the prospective Windows Server 2008 server may need to be in place as well. To prepare the environment, the schema will have to be modified, permissions will be modified and various other configurations will be performed on a domain controller. The Exchange 2010 RC is compiled only for 64 bits. Customers may not have a domain controller running a 64 bit version of Windows Server 2003. So you will have to have a 64 bit platform to run the preparation steps.
If you are going to use the Windows Server 2008 server, you will also need to install the Active Directory management tools which includes ldifde.exe. The following command in bold will install these tools:
c:\exchange 2010>ServerManagerCmd -i RSAT-ADDS
..
Start Installation...
[Installation] Succeeded: [Remote Server Administration Tools] Role
Administration Tools.
[Installation] Succeeded: [Remote Server Administration Tools] Active Directory
Domain Services Tools.
Warning: [Installation] Succeeded: [Remote Server Administration Tools] Server
for NIS Tools. You must restart this server to finish the installation process.
Warning: [Installation] Succeeded: [Remote Server Administration Tools] Active
Directory Domain Controller Tools. You must restart this server to finish the ins
tallation process.
<100/100>
Success: A restart is required to complete the installation.
Another requirement is PowerShell 2.0. This is not available on Windows Server 2008 installations. This is not available on the installation bits for the Exchange 2010 RC version either. PowerShell 2.0 doesn’t appear to be released at an RTM release. The setup.exe program sends you to a web site to download the "Core PowerShell & WinRm for Vista and Windows Server 2008" x64 : http://connect.microsoft.com/windowsmanagement/downloads
There are a series of preparatory commands which are run on the Active Directory forest using the Exchange 2010 setup.com tool:
- /PrepareLegacyExchangePermissions (/pl) prepares “legacy Exchange permissions in every domain in the forest containing Exchange Enterprise Servers and Exchange Domain Servers groups.”
http://technet.microsoft.com/en-us/library/dd298100(EXCHG.140).aspx
- /Prepareschema (/ps) modifies the schema as other installations of Exchange have done in the past.
- /PrepareAD (/p) creates the organization structure in Active Directory if not already there. In addition, it creates the Microsoft Exchange Security Groups organizational unit and the groups that go into it. And lots more!
- /PrepareDomain (/pd) primarily sets permissions on the domain for the newly created groups. This is run on all domains which will have an Exchange server in it.
The first two, /pl and /ps are executed within the /p command so you could execute just that one. Also, the first one /pl is also executed by /ps. The reasoning for separating the commands is to allow different users to run them on at a time. /Pl and /pd require a member of the Domain Admins group. /Ps requires a user account that is a member of the Schema Admins and the Enterprise Admins group. /P requires just a member of the Enterprise Admin group. So the separation can assign specific parts to appropriate parties.
Running the command results as follows:
c:\exchange 2010>setup.com /preparelegacyexchangepermissions
Welcome to Microsoft Exchange Server 2010 Unattended Setup
By continuing the installation process, you agree to the license terms of
Microsoft Exchange Server 2010. If you don't accept these license terms,
please cancel the installation. To review these license terms, please go to
http://go.microsoft.com/fwlink/?LinkId=150127&clcid=0x409/
...............
No key presses were detected. Setup will continue.
Preparing Exchange Setup
Copying Setup Files ......................... COMPLETED
No server roles will be installed
Performing Microsoft Exchange Server Prerequisite Check
Organization Checks ......................... COMPLETED
Configuring Microsoft Exchange Server
Updating legacy permissions ......................... COMPLETED
The Microsoft Exchange Server setup operation completed successfully.
The other commands look very similar in how they run. I ran them in succession as a member of the Enterprise Admin & Schema Admin groups without much difficulty.
Now, the Exchange environment is now properly prepared to allow the installation of Exchange 2010. In the next blog, we’ll run through the typical installation with plans on adding and additional Exchange server to provide high availability of the MB, CAS and HT services in the future.
Monday, November 2, 2009
Exchange 2010 - Planning and Coexistence
Given my current employment, I’ve got the time to devote to studying Exchange 2010. To hone my skills, I plan posting my notes on this beloved blog to encourage the masses to migrate to Exchange 2010 and hire me to do it.
Currently, Exchange 2010 is in the Release Candidate phase of development. This means it is one step before the Release (Ready?) to Market (RTM) or gold standard. Thus it is very similar to what you will see on Exchange 2010 when it hits production but there may be slight difference. It can be downloaded for evaluation from the Microsoft web site. In addition, the technical writing squirrels are catching up on the documentation to post to the Technet site too. There will be differences in what is posted now compared to what was and what will be concerning this version. This should be a little warning since what I write is predominately based on what I find on the Technet site.
Planning to implement Exchange 2010 is similar to Exchange 2007 (Ex2k7). This release was a departure from the previous Exchange releases in the architecture by implementing multiple roles an Exchange server could be assigned. Previous versions had two, the front end and back end options, for server roles. The front end managed the client web access and the inbound/outbound internet SMTP traffic. Exchange 2010 offers the same roles as Ex2k7: mailbox (MB), hub transport (HT), client access services (CAS), edge transport (ET) and unified messaging (UM). So the decision of where and how to implement these roles needs to be considered in the planning stage.
The biggest difference between 2007 and 2010 is the mailbox (MB) role’s high availability feature. Gone away are 2007’s Single Copy Cluster (SCC) and Local Continuous Copy Replication (LCR). The 2010’s new fandango for handling this provides a database replication to other Exchange servers where the database is highly available across multiple servers. We’ll get into this in more detail in later blogs. The up shot to planning is certain restrictions with 2007 are removed when placing roles. In a medium organization which wanted high availability for each role of mail service would need at least four servers, two clustered mailbox servers and two network load balanced CAS/HT servers. The clustered mailbox prevented additional roles being installed on it. We should now be able to knock this down to two since HT and CAS can be installed on the equivalent clustered mailbox server. The clustering technology has changed significantly with Windows Server 2008 so it is not dependent on shared storage; the Exchange 2010 capability makes clustering hardly server dependent.
Given the needed brevity of blogs, I won’t detail the decision points on role placement in this discussion. You can check out the Technet site and msexchange.org concerning Ex2k7 architecture if you would like more info on it. In addition, the majority of Exchange deployments include just single servers with third party implementations for anti-spam or unified communications. I believe we should concentrate on the majority to limit the discussion.
Another key similarity with Exchange 2007 is the lack of in-place upgrade capability. Overall, the in-place upgrade is not a recommended method of migration for email systems. The possiblity of breaking your working email server by running the setup.exe utility doesn’t emote a “warm and fuzzy” feeling especially when it is a business critical system. The upgrade restriction is primarily due to the 64 bit architecture and the requirement of Windows Server 2008 for the hosted operating system. Without the in-place upgrade, all customers will need to consider coexistence scenarios.
Here are the highlights on planning Exchange 2010 coexistence implementations:
- Exchange 2010 is supported with Ex2k3 SP2 and Ex2k7 SP2. Ex2k is not supported. This needs to be upgraded to Ex2k3 before you can get busy.
- Ex2k3 native mode is the minimum accepted configuration for the Exchange organization.
- Active Directory can be supported by Windows Server 2003 SP1 or higher. The Schema and GCs can be Windows Server 2003 servers.
- The Active Directory forest and domain function levels must be Windows Server 2003 or higher.
- Exchange isn’t supported on domain controllers. The exception is Small Business Server implementations and this is actually a different operating system from Windows Server 2008.
I expect the majority of customers considering Exchange 2010 will have Ex2k3 existing implementations. They have developed a pretty stable environment with Ex2k3 but see the benefits of the 64 bit processing performance. They may also be very interested in the high availability/site resilience solution since it has drastically reduced the price tag of it. Those who have implemented Ex2k7 may not have much impetus to upgrade unless they have Microsoft Software Assurance. I expect the economy will suppress even this move to limit the cost in man hours.
Since the architecture is similar to Ex2k7, the migration path is similar also. First, a CAS role is integrated into the organization. Legacy OWA requests will be redirected by the Exchange 2010 CAS role to this server. Thus the Exchange 2010 CAS will replace the Ex2k3 Front end server for Internet based OWA traffic. (When I refer to OWA, I also am including ActiveSync, Outlook Anywhere, POP3 and IMAP4) Second, the implementation of the Hub Transport role will replace the other component of the front end server by receiving the Internet based SMTP traffic. Finally, the mailbox servers are implemented and mailboxes are gradually moved from the Ex2k3 backend servers. A typical install which includes the CAS, HT and MB roles all in one server is acceptable in migration but you will concentrate on the configuring each role in the same order.
This is how Microsoft lays out the upgrade path which is how I’ll perform the migration in the lab:
1. Upgrade to proper SP level.
2. Install the Ex2010 with the follow role order CAS, HT, UM and MB
3. Configure legacy host name for the FE server. This allows users to continue have access to the Ex2k3 FE going through the Ex2010 server. The Ex2010 server will redirect traffic to this name "seamlessly."
4. Redirect internet bound incoming traffic to CAS and HT roles by reassigning the external name. This will result in the FE servers becoming secondary.
5. Move mailboxes to Ex2010.
The “legacy host name” step renames the FE server and reassigns its name to the Ex2010 server. For example, your company’s FE name is mail.domain.com. This will be changed to “legacy.domain.com” and the CAS server will get the mail.domain.com. SSL and forms based authentication is required on the Ex2k3 server for this to work.
I’ll stop here to keep your eyes from glazing over. Next time, we’ll walk through the preparation of an Exchange 2k3 environment.
Currently, Exchange 2010 is in the Release Candidate phase of development. This means it is one step before the Release (Ready?) to Market (RTM) or gold standard. Thus it is very similar to what you will see on Exchange 2010 when it hits production but there may be slight difference. It can be downloaded for evaluation from the Microsoft web site. In addition, the technical writing squirrels are catching up on the documentation to post to the Technet site too. There will be differences in what is posted now compared to what was and what will be concerning this version. This should be a little warning since what I write is predominately based on what I find on the Technet site.
Planning to implement Exchange 2010 is similar to Exchange 2007 (Ex2k7). This release was a departure from the previous Exchange releases in the architecture by implementing multiple roles an Exchange server could be assigned. Previous versions had two, the front end and back end options, for server roles. The front end managed the client web access and the inbound/outbound internet SMTP traffic. Exchange 2010 offers the same roles as Ex2k7: mailbox (MB), hub transport (HT), client access services (CAS), edge transport (ET) and unified messaging (UM). So the decision of where and how to implement these roles needs to be considered in the planning stage.
The biggest difference between 2007 and 2010 is the mailbox (MB) role’s high availability feature. Gone away are 2007’s Single Copy Cluster (SCC) and Local Continuous Copy Replication (LCR). The 2010’s new fandango for handling this provides a database replication to other Exchange servers where the database is highly available across multiple servers. We’ll get into this in more detail in later blogs. The up shot to planning is certain restrictions with 2007 are removed when placing roles. In a medium organization which wanted high availability for each role of mail service would need at least four servers, two clustered mailbox servers and two network load balanced CAS/HT servers. The clustered mailbox prevented additional roles being installed on it. We should now be able to knock this down to two since HT and CAS can be installed on the equivalent clustered mailbox server. The clustering technology has changed significantly with Windows Server 2008 so it is not dependent on shared storage; the Exchange 2010 capability makes clustering hardly server dependent.
Given the needed brevity of blogs, I won’t detail the decision points on role placement in this discussion. You can check out the Technet site and msexchange.org concerning Ex2k7 architecture if you would like more info on it. In addition, the majority of Exchange deployments include just single servers with third party implementations for anti-spam or unified communications. I believe we should concentrate on the majority to limit the discussion.
Another key similarity with Exchange 2007 is the lack of in-place upgrade capability. Overall, the in-place upgrade is not a recommended method of migration for email systems. The possiblity of breaking your working email server by running the setup.exe utility doesn’t emote a “warm and fuzzy” feeling especially when it is a business critical system. The upgrade restriction is primarily due to the 64 bit architecture and the requirement of Windows Server 2008 for the hosted operating system. Without the in-place upgrade, all customers will need to consider coexistence scenarios.
Here are the highlights on planning Exchange 2010 coexistence implementations:
- Exchange 2010 is supported with Ex2k3 SP2 and Ex2k7 SP2. Ex2k is not supported. This needs to be upgraded to Ex2k3 before you can get busy.
- Ex2k3 native mode is the minimum accepted configuration for the Exchange organization.
- Active Directory can be supported by Windows Server 2003 SP1 or higher. The Schema and GCs can be Windows Server 2003 servers.
- The Active Directory forest and domain function levels must be Windows Server 2003 or higher.
- Exchange isn’t supported on domain controllers. The exception is Small Business Server implementations and this is actually a different operating system from Windows Server 2008.
I expect the majority of customers considering Exchange 2010 will have Ex2k3 existing implementations. They have developed a pretty stable environment with Ex2k3 but see the benefits of the 64 bit processing performance. They may also be very interested in the high availability/site resilience solution since it has drastically reduced the price tag of it. Those who have implemented Ex2k7 may not have much impetus to upgrade unless they have Microsoft Software Assurance. I expect the economy will suppress even this move to limit the cost in man hours.
Since the architecture is similar to Ex2k7, the migration path is similar also. First, a CAS role is integrated into the organization. Legacy OWA requests will be redirected by the Exchange 2010 CAS role to this server. Thus the Exchange 2010 CAS will replace the Ex2k3 Front end server for Internet based OWA traffic. (When I refer to OWA, I also am including ActiveSync, Outlook Anywhere, POP3 and IMAP4) Second, the implementation of the Hub Transport role will replace the other component of the front end server by receiving the Internet based SMTP traffic. Finally, the mailbox servers are implemented and mailboxes are gradually moved from the Ex2k3 backend servers. A typical install which includes the CAS, HT and MB roles all in one server is acceptable in migration but you will concentrate on the configuring each role in the same order.
This is how Microsoft lays out the upgrade path which is how I’ll perform the migration in the lab:
1. Upgrade to proper SP level.
2. Install the Ex2010 with the follow role order CAS, HT, UM and MB
3. Configure legacy host name for the FE server. This allows users to continue have access to the Ex2k3 FE going through the Ex2010 server. The Ex2010 server will redirect traffic to this name "seamlessly."
4. Redirect internet bound incoming traffic to CAS and HT roles by reassigning the external name. This will result in the FE servers becoming secondary.
5. Move mailboxes to Ex2010.
The “legacy host name” step renames the FE server and reassigns its name to the Ex2010 server. For example, your company’s FE name is mail.domain.com. This will be changed to “legacy.domain.com” and the CAS server will get the mail.domain.com. SSL and forms based authentication is required on the Ex2k3 server for this to work.
I’ll stop here to keep your eyes from glazing over. Next time, we’ll walk through the preparation of an Exchange 2k3 environment.
Friday, September 4, 2009
Symantec Enterprise Vault
A lesson from the field for Enterprise Vault. 8390 Errors. These usually mean that you need to put the DisableLoopbackCheck =1 DWORD in the HKLM\SYSTEM\CurrentControlSet\Control\Lsa … But not always. Look for name resolution issues in your environment. Cure these two things and you will most likely solve the problems.
Need to change your Vault service account password? Use the Site Settings where the Service Account tab is located. When you put in the new password it will push the new password to all the services on your site—including the FSA Agent passwords on your file servers. Make sure and relocate the clusters to the passive nodes and run this process again—including and clustered file servers. But that's not all. I have seen a stubborn issue with the Storage Service. Go into Component Services, My Computer, DCOM Settings, and find the StorageServer DCOM application. Right-click on that guy and select Properties. Under the Identity Tab, enter in the new password. There may be other Enterprise Vault DCOM Applications that require this little change. Moral of the story: Don't change that password unless you really have to.
Friday, July 10, 2009
SharePoint 2007 WSS 3.0 Service Pack 2
Several of my clients have installed SP2 for MOSS 2007. Aside from a glitch which puts the farm in trial mode--which has been fixed before the 180 days expiration--I have heard nothing good or bad about this release.
I did some timings (based solely on logs) on the length of incremental crawls, content deployment, backups, etc. I don't really notice a difference, but I didn't set this up scientifically by keeping the content of my farm static. Quite contrary, I merged a site collection then split another. I also added some new content.
So what are some other stories out there with the success or failure of SP2 for MOSS / WSS?
Please leave comments. I will edit this post if I find any new tidbits.
I did some timings (based solely on logs) on the length of incremental crawls, content deployment, backups, etc. I don't really notice a difference, but I didn't set this up scientifically by keeping the content of my farm static. Quite contrary, I merged a site collection then split another. I also added some new content.
So what are some other stories out there with the success or failure of SP2 for MOSS / WSS?
Please leave comments. I will edit this post if I find any new tidbits.
Wednesday, July 8, 2009
Notes to SharePoint migration - Phase Two Design and testing
Once you've completed the Discovery phase of your Notes to SharePoint migrations (see the steps here:
http://moss-exchange.blogspot.com/2009/05/notes-to-sharepoint-migration-phase-one.html ) you are ready for the next steps.
This phase is where you design the migration. First, you need a target environment. If you already have a SharePoint environment setup, it's likely organized by department or geography. This works well for most Notes applications as most are department specific. If they are global, enterprise applications such as a robust employee directory, these can be organized somewhat easily into any SharePoint implementation. Site design, taxonomy, and governance are different discussions. You should have a clear direction for your MOSS implementation, yet be flexible to add features or scale out as your organization consumes the technology differently than originally anticipated. It happens.
Which Tool?
At this point, you should have decided upon a migration tool. I use the Quest tools, but others swear by the Tzunami tools. I like to have the Quest Development Studio, Notes Migrator for SharePoint, and a backup solution. I like the AvePoint backup and recovery tool, but also have had good results with the Quest tool. Each tool I have mentioned has it's advantages and pain points. I make no claim to their effectiveness. You can use your own custom coding to replace the Development Studio or Quest tools. I don't write code unless I absolutely have to as it really slows down the projects when you suddenly have a development effort. Sometimes it can't be helped, but I have found for most things in Notes / Domino / Quickplace I can readily replicate in SharePoint in a few hours or days.
The Microsoft AppTransporter might assist with some simple applications, but it's free. You get what you pay for. Buy a robust migration tool and get this project behind you.
Architecture:
I use 32-bit front-end servers with 64-bit backend server(s). This really helps with iFilters, migration tool configuration, and other compatibility issues. Some enterprises have switched to 64-bit servers and aren't looking back. This requires some work-arounds and changes the steps of the migration, but it isn't a showstopper.
Things you just can't do:
If you have a distributed workforce that synchronizes their Notes databases locally before heading to the field, you have some work cut out for you. There are third party applications to replicate SharePoint content locally or two remote farms across the WAN.
These really help address the issue of the distributed architecture of Notes vs the single farm/site limitations of SharePoint. Another option for less complex Domino applications is to use Groove for a local copy of the workspace. This means Office 2007 and potentially a Groove Server added to the mix.
What version of SharePoint?
First, you need to know which version of SharePoint you need. There is WSS, MOSS Standard, and MOSS Enterprise. We'll work our way down in reverse order of expense:
If you need InfoPath forms, connection to external data sources/applications or Excel Services you have to spring for the Enterprise version.
If you don't need any of the above, but need publishing, life cycle management, user profiles, mysites, etc you need at least the Standard version of MOSS.
If you don't need any of the above but have Office integration needs, document libraries, basic workflow, collaboration needs, and simple site layout WSS is the best and least expensive solution. Contact a knowledgable resource regarding your licensing and requirements. If you have mostly very basic Notes applications and simply want to retire Notes, start with WSS. You can fairly easily migrate from WSS to MOSS if you outgrow the features of WSS.
The Migration Tool:
Start with the easy Document Libraries or other list type applications to get a feel for the migration tool and how it works. If your farm is already in production, setup a dev and / or test farm. Read the manual. This is a complex undertaking. Migrations are never straightforward. Migrate and see what happens. You will likely need to delete your first few attempts.
Migration to a Publishing Farm:
A technique I find particularly helpful when a client is already using MOSS in production is to migrate to a test or publishing farm. You can then deploy the content to a new site in the production farm. This gives the QA team a chance to bless the application. I have had trouble deploying content to existing pages and have really only had luck starting with a new subsite or page. This issue was supposed to be fixed in MOSS SP2, but I haven't verified it. I have yet to see Microsoft admit the feature was broken, but it was definitely unable to update an existing page with dynamic content changes. Leave a comment if you need help with this and I can explain this in more detail.
Test, test, test:
Read the product literature carefully. Learn how the ACLs in Notes translate to the ACLs and audiences in SharePoint. Work with Forms libraries. Try the different settings. Get familiar with the tool.
Leave a comment if you have anything to add or ask!
http://moss-exchange.blogspot.com/2009/05/notes-to-sharepoint-migration-phase-one.html ) you are ready for the next steps.
This phase is where you design the migration. First, you need a target environment. If you already have a SharePoint environment setup, it's likely organized by department or geography. This works well for most Notes applications as most are department specific. If they are global, enterprise applications such as a robust employee directory, these can be organized somewhat easily into any SharePoint implementation. Site design, taxonomy, and governance are different discussions. You should have a clear direction for your MOSS implementation, yet be flexible to add features or scale out as your organization consumes the technology differently than originally anticipated. It happens.
Which Tool?
At this point, you should have decided upon a migration tool. I use the Quest tools, but others swear by the Tzunami tools. I like to have the Quest Development Studio, Notes Migrator for SharePoint, and a backup solution. I like the AvePoint backup and recovery tool, but also have had good results with the Quest tool. Each tool I have mentioned has it's advantages and pain points. I make no claim to their effectiveness. You can use your own custom coding to replace the Development Studio or Quest tools. I don't write code unless I absolutely have to as it really slows down the projects when you suddenly have a development effort. Sometimes it can't be helped, but I have found for most things in Notes / Domino / Quickplace I can readily replicate in SharePoint in a few hours or days.
The Microsoft AppTransporter might assist with some simple applications, but it's free. You get what you pay for. Buy a robust migration tool and get this project behind you.
Architecture:
I use 32-bit front-end servers with 64-bit backend server(s). This really helps with iFilters, migration tool configuration, and other compatibility issues. Some enterprises have switched to 64-bit servers and aren't looking back. This requires some work-arounds and changes the steps of the migration, but it isn't a showstopper.
Things you just can't do:
If you have a distributed workforce that synchronizes their Notes databases locally before heading to the field, you have some work cut out for you. There are third party applications to replicate SharePoint content locally or two remote farms across the WAN.
These really help address the issue of the distributed architecture of Notes vs the single farm/site limitations of SharePoint. Another option for less complex Domino applications is to use Groove for a local copy of the workspace. This means Office 2007 and potentially a Groove Server added to the mix.
What version of SharePoint?
First, you need to know which version of SharePoint you need. There is WSS, MOSS Standard, and MOSS Enterprise. We'll work our way down in reverse order of expense:
If you need InfoPath forms, connection to external data sources/applications or Excel Services you have to spring for the Enterprise version.
If you don't need any of the above, but need publishing, life cycle management, user profiles, mysites, etc you need at least the Standard version of MOSS.
If you don't need any of the above but have Office integration needs, document libraries, basic workflow, collaboration needs, and simple site layout WSS is the best and least expensive solution. Contact a knowledgable resource regarding your licensing and requirements. If you have mostly very basic Notes applications and simply want to retire Notes, start with WSS. You can fairly easily migrate from WSS to MOSS if you outgrow the features of WSS.
The Migration Tool:
Start with the easy Document Libraries or other list type applications to get a feel for the migration tool and how it works. If your farm is already in production, setup a dev and / or test farm. Read the manual. This is a complex undertaking. Migrations are never straightforward. Migrate and see what happens. You will likely need to delete your first few attempts.
Migration to a Publishing Farm:
A technique I find particularly helpful when a client is already using MOSS in production is to migrate to a test or publishing farm. You can then deploy the content to a new site in the production farm. This gives the QA team a chance to bless the application. I have had trouble deploying content to existing pages and have really only had luck starting with a new subsite or page. This issue was supposed to be fixed in MOSS SP2, but I haven't verified it. I have yet to see Microsoft admit the feature was broken, but it was definitely unable to update an existing page with dynamic content changes. Leave a comment if you need help with this and I can explain this in more detail.
Test, test, test:
Read the product literature carefully. Learn how the ACLs in Notes translate to the ACLs and audiences in SharePoint. Work with Forms libraries. Try the different settings. Get familiar with the tool.
Leave a comment if you have anything to add or ask!
Subscribe to:
Posts (Atom)
