Friday, June 24, 2011

BES AgentOptimizeAlgorithm

I had been long looking for the feature to distribute agents evening to speed up mailbox scanning processing particular after we upgrade Exchange 2003 to Exchange 2007 a couple years ago. I was always told that sorry we cannot do that by RIM support. Finally I got the postive answer from RIM by editting register key.
 
By default, if you run MSDE, BES only supports two dynamic agents per server. If you run Full MS SQL edition for BES database, you can run as many as 20 agents (RIM recommends you should run less than 10 agents per BES). BES assigns users to agents per Exchange servers and up to 400 users per agent. Since we had migrated all 5000 user mailboxes to one Exchange 2007 CCR server, for about 700 users per BES HA, by default, it will allocate 400 users for two dynamic agents, the message delivery significantly delays whenever we failover BES (it could take about two hours to complete the sync) that made BES failover useless.
 
Now that after we have implemented AgentOptimizeAlgorithm, and changed from two agents to five agents for 800 users per HA server, message delivery delay has been reduced from 2 hours to 15 minutes.
 
Also if you use Exchange 2010, BES basically sees the CAS as the mailbox with 2010 (instead of the actual mailbox server the user is on, assuming you have installed the CAS on a separate server). Because of this, if you have multiple CAS behind a load balancer, it throws the "keep users from the same exchange server on the same BES" rule out. This is our situation and the guidance given to us by RIM is to implement the AgentOptimizeAlgorithm to 1 (simple algorithm) to randomly assign users to an Agent instead of keeping an Agent to one mail server:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Research In Motion\BlackBerry Enterprise Server\Dispatcher.
DWORD value is 1 - the simple algorithm is used.
DWORD value is 2 - the complex algorithm is used.
The Default value is 2. a complex algorithm, Note: if you don't see the key, create the REG-Dword key.
 
Enabling Simple Messaging Agent Distribution Algorithm
 
The distribution algorithm can be changed with the DWORD registry key AgentOptimizeAlgorithm located in
32 bit - HKEY_LOCAL_MACHINE\SOFTWARE\Research In Motion\BlackBerry Enterprise Server\Dispatcher.
64bit - HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Research In Motion\BlackBerry Enterprise Server\Dispatcher.
DWORD value is 1 - the simple algorithm is used.
DWORD value is 2 - the complex algorithm is used.
The Default value is 2.
 
If the registry key does not exist, create it.
 
No advanced logic is used in this process.
 
BlackBerry smartphone users are simply distributed evenly across the number of agents specified in the DWORD registry key NumAgents located in:
32bit - HKEY_LOCAL_MACHINE\SOFTWARE\Research In Motion\BlackBerry Enterprise Server\Agents.
64bit - HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Research In Motion\BlackBerry Enterprise Server\Agents.
Default value is 5, do not increase it higher than 10.
Note: If the above registry keys do not exist, they need to be created.
 
Note: A maximum of 2 Messaging Agents will be created if the configuration database is on Microsoft SQL Database Engine (MSDE).  Move the configuration database to SQL 2005 Express using KB03112.
 
 After talking with RIM on this one, it is my understanding that if you are completely Exchange 2010 or 2007 (instead of mixed mode with 2003) and you have implemented EWS using the traittool on the global level (and not per server or agent) then you can completely uninstall MAPI since it is no longer being used (KEEP CDO THOUGH!). Of course I would test in a lab first, but this is what I intend to do after we are finished migrating to 2010.
 
Note: We run BES 5.0.3 HA with Intel Powerful processors (16 virtual processors with 32 GB RAM)
Posted by at No comments:

"Upgrade Issues" prompt appears when upgrading to BlackBerry Enterprise Server 5.0 SP3 HA

Just done BES 5.02 HA to BES 5.0.3 recently. Since starting from BES 5.0.3 Integrated MDS is no longer support, you may get the following error once you do the upgrade:
 
When upgrading to BlackBerry® Enterprise Server 5.0 SP3, a prompt titled Upgrade Issues may appear that contains wording similar to the following:
The setup application found the BlackBerry MDS Integration Service on the following computers in the BlackBerry Domain:

<ComputerName>

Before you can continue the current upgrade process you must un-install the BlackBerry MDS Integration Service. For more information, see the BlackBerry Enterprise Server Upgrade Guide
 
Cause 1
 
The BlackBerry® Mobile Data System Integration Service (MDS-IS) must be uninstalled from the BlackBerry Domain before an upgrade to BlackBerry Enterprise Server 5.0 SP3 can continue.
Cause 2
 
The BlackBerry Mobile Data System Integration Service (MDS-IS) SQL backup must be deleted from the server so the install of the BlackBerry Enterprise Server 5.0 SP3 can continue.
 
Resolutions:
 
Please choose the appropriate option below and follow the associated steps, depending on the version of the BlackBerry Enterprise Server that is running, or the resolution that fits your circumstances.
The BlackBerry Mobile Data System Integration Service (MDS-IS) must be uninstalled from the BlackBerry Domain before an upgrade to BlackBerry Enterprise Server 5.0 SP3 can continue.
Resolution 1
 
Option - Using CreateDB executable included with BlackBerry Enterprise Server 5.0 SP3
Supported versions:
  • BlackBerry Enterprise Server 4.1 SP7 to 5.0 SP2 MR5 
Related Steps
  1. Extract the BlackBerry Enterprise Server 5.0 SP3 software to a folder.
  2. Navigate to the folder above and double-click the Database folder.
  3. In the Database folder, right-click the BESMgmt.cfg file and choose to open it with Notepad.
  4. In this file, make the following changes:
    1. For CMD=Install, change Install to Upgrade.
    2. For DATABASE_NAME=BESMgmt, replace BESMgmt with the name of your BlackBerry Configuration Database, if different.
    3. For SERVER=local if required, update this value with the name of the Microsoft® SQL Server® that the BlackBerry Configuration Database is hosted on. If an instance is used, specify it as SERVERNAME\INSTANCENAME.
    4. If necessary, populate the MSSQL_PORT= value with the port of your Microsoft SQL Server if different than 1433.
    5. If using Microsoft SQL Server Authentication, populate the USERID= and PASSWORD= values with a Microsoft SQL Server Authentication account that has System Administrator privileges.
    6. Change BACKUP=false to BACKUP=true.
    7. If required, change BES_TYPE=Exchange to Domino if you are running BlackBerry® Enterprise Server for IBM® Lotus® Domino®.
  5. From the menu in Notepad, click File > Save and close the file.
  6. Double-click the CreateDB.exe file in the same folder as the BESMgmt.cfg file.
  7. Proceed with the installation of the BlackBerry Enterprise Server 5.0 SP3 upgrade.

Option - Using installation software and the BlackBerry Administration Service to remove the BlackBerry MDS Integration Service

Supported versions:
  • BlackBerry Enterprise Server 5.0 SP1 to 5.0 SP2 MR5 
Installation Related Steps
  1. Locate or obtain the installation file for BlackBerry Enterprise Server 5.0 SP1 or SP2 and extract it to a folder.
  2. Locate and double-click the Setup.exe file from the above folder.
  3. Choose your language from the drop-down list.
  4. Accept the license agreement and click Next.
  5. Leave all database details as is for your deployment while clicking Next until you reach the Setup Options screen.
  6. On the Setup Options screen, clear the check box beside the BlackBerry MDS Integration Service and click Next.
  7. Click Next, and complete the rest of the setup screens as you would for a new installation.
  8. If prompted, reboot the computer.

    Note: If you are running BlackBerry Enterprise Server 5.0 SP1, skip the steps below and proceed to the BlackBerry Administration Service Steps.
  9. If you don't already have it available, obtain the BlackBerry Enterprise Server 5.0 SP2 MR2 or MR3 software from http://www.blackberry.com/support/downloads.
  10. Extract BlackBerry Enterprise Server 5.0 SP2 MR2 or MR3 software to a folder. Ensure this is a different folder than Step 1 above.
  11. Locate and double-click the Setup.exe file from the folder in Step 10.
  12. Choose your language and click OK.
  13. Click Next.
  14. Enter your service account password and click Next.
  15. Once the installation has completed, reboot the computer.
  16. Click Next on all outstanding prompts for the rest of the installation, leaving all existing options unchanged.
  17. Click Start Services and then click Next.
BlackBerry Administration Service Steps
  1. Once the installation has completed, log in to the BlackBerry Administrative Service.
  2. Under Servers and Components, expand BlackBerry Solution Topology > BlackBerry Domain > Component View> BlackBerry Enterprise Server, and click the server name.
  3. Scroll to the bottom of the resulting page and click Edit Instance.
  4. In the Supported MDS Integration Service instance names, click the drop-down list and select the blank space above the existing entry.
    Click Save All.
  5. Go back to Servers and Components, expand BlackBerry Solution Topology > BlackBerry Domain, and click Component View.
  6. Scroll to the MDS Integration Service heading, and click the Delete icon to delete the instance.
  7. Click Yes - Delete the instance.
  8. When prompted to confirm, click Yes - Delete the instance.
  9. From Windows Services restart the services named BlackBerry Administration Service - Application Server and BlackBerry Administration Service - Native Code Container
Once the above steps are completed, proceed with the upgrade to BlackBerry Enterprise Server 5.0 SP3. Please refer to the Installation Guide for details on completing the upgrade.
Option - Using the installation software and the BlackBerry Manager to remove the BlackBerry MDS Integration Service
Supported versions:
  • BlackBerry Enterprise Server 4.1 SP7
Installation Related Steps
  1. Navigate to Start > Control Panel > Add Remove Programs.
  2. Click the Remove button beside the BlackBerry Enterprise Server.
  3. Click Yes to the resulting prompt that asks if you are sure that you want to remove the software.
  4. If you wish to keep your current logs, click No to the warning about removing them.

    Note: If BlackBerry Manager is installed on a remote computer, there is no need to reinstall the BlackBerry Enterprise Server.  Please proceed to the BlackBerry Manager Related Steps below.
  5. Locate or obtain the full installation file or files used to install or upgrade BlackBerry Enterprise Server 4.1 SP7 software and extract it to a folder.

    Note: If the file that was used to install BlackBerry Enterprise Server 4.1 SP7 has the term upgrader in it, please obtain a full installation file from the BlackBerry Expert Support Center.
  6. Locate and double-click the Setup.exe file from the above folder.
  7. Choose your language from the drop-down list.
  8. Accept the license agreement and click Next.
  9. At the Setup Type screen, select an option that does not include the BlackBerry MDS Integration Service, and click Next.
  10. Click Next at the Preinstallation Checklist screen.
  11. Enter your service account password and the BlackBerry Enterprise Server name (if different from the default populated) and click Next.
  12. Select whether or not you are using a local or remote Microsoft SQL Server and click Next.
  13. Click Next at the Installation Summary screen.
  14. Once the installation is complete, reboot the computer if you are not prompted to do so.
  15. After the reboot, enter database information for your installation and click Next.
    Complete all other prompts that should have pre-existing information present while clicking Next, and then click Start Service, then click Finish.
BlackBerry Manager Related Steps
  1. Open the BlackBerry Manager by navigating to Start > Programs > BlackBerry Enterprise Server, and click BlackBerry Manager.
  2. For each BlackBerry Enterprise Server in the left navigational bar, perform the following:
    1. Select the BlackBerry Enterprise server from the left navigational bar.
    2. On the right pane, click the Server Configuration tab.
    3. In the pane below, click Edit Properties.
    4. In this new window, click MDS Integration Service on the left navigation area.
    5. On the right, click the URL beside BlackBerry MDS Integration Service Server URL, and choose Default.
    6. Click Apply then OK.
  3. Click the BlackBerry Domain icon on the left navigation bar.
  4. On the right, click the drop-down list named Service Control & Customization.
  5. Click the option named Delete MDS Integration Service.
  6. In this new window, select the MDS Integration Service entry and click Remove.
  7. Click Apply, then OK.
Once the above steps are completed, proceed with the upgrade to BlackBerry Enterprise Server 5.0 SP3. Please refer to the Installation Guide for details on completing the upgrade.
The BlackBerry Mobile Data System Integration Service (MDS-IS) SQL backup must be deleted from the server so the install of the BlackBerry Enterprise Server 5.0 SP3 can continue.
Resolution 2
1) Browse to <drive>:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Backup
2) Delete the MDSIS backup files.
 
Additional Information
The BlackBerry MDS Integration Service is only responsible for facilitating connectivity for BlackBerry MDS Runtime Applications, and has no effect on Internet or intranet browsing, nor other third-party Java® or web applications.
Note: BlackBerry Enterprise Server 5.0 SP2 Maintainance Release 2, 3, 4 or 5 are required to be installed as they fix an issue related to removing the BlackBerry Mobile Data System - Integration Service (MKS762391) when using the BlackBerry Administration Service.
 
Note: We did option 2, we still have the issue. Option1 is the best choice.
Posted by at No comments:

Friday, June 3, 2011

Exchange 2010, say good bye to single instance storage (SIS)

 
 
In Exchange Server 2010, there is no more single instance storage (SIS). To help understand why SIS is gone, let's review a brief history of Exchange.
During the development of Exchange 4.0, we had two primary goals in mind, and SIS was borne out of these goals:
  1. Ensure that messages were delivered as fast and as efficient as possible.
  2. Reduce the amount of disk space required to store messages, as disk capacity was premium.
Exchange 4.0 (and, to a certain extent, Exchange 5.0 and Exchange 5.5) was really designed as a departmental solution. Back then, users were typically placed on an Exchange server based on their organization structure (often, the entire company was on the same server).  Since there was only one mailbox database, we maximized our use of SIS for both message delivery (only store the body and attachments once) and space efficiency. The only time we created another copy within the store was when the user modified their individual instance.
For almost 19 years, the internal Exchange database table structure has remained relatively the same:
Then came Exchange 2000.  In Exchange 2000, we evolved considerably - we moved to SMTP for server-to-server connectivity, we added storage groups, and we increased the maximum number of databases per server.  The result was a shift away from a departmental usage of Exchange to enterprise usage of Exchange.  Moreover, the move to 20 databases reduced SIS effects on space efficiency, as the likelihood that multiple recipients were on the same database decreased.  Similarly, message delivery was improved by our optimizations in transport, so transport no longer benefited as much from SIS either.
With Exchange 2003, consolidation of servers took off in earnest due to features like Cached Exchange Mode.  Again the move away from departmental usage continued.  Many customers moved away from distributing mailboxes based on their organization structure to randomization of the user population across all databases in the organization.  Once again, the space efficiency effects of SIS were further reduced.
In Exchange 2007, we increased the number of databases you could deploy, which again reduced the space efficiency of SIS. We further optimized transport delivery and completely removed the need for SIS from a transport perspective.  Finally, we made changes to the information store that removed the ability to single instance message bodies (but allowed single instancing of attachments). The result was that SIS no longer provided any real space savings - typically only about 0-20%.
One of our main goals for Exchange 2010 was to provide very large mailboxes at a low cost. Disk capacity is no longer a premium; disk space is very inexpensive and IT shops can take advantage of larger, cheaper disks to reduce their overall cost. In order to leverage those larger capacity disks, you also need to increase mailbox sizes (and remove PSTs and leverage the personal archive and records management capabilities) so that you can ensure that you are designing your storage to be both IO efficient and capacity efficient.
During the development of Exchange 2010, we realized that having a table structure optimized for SIS was holding us back from making the storage innovations that were necessary to achieve our goals. In order to improve the store and ESE, to change our IO profile (from many, small, random IOs to larger, fewer, more sequential IOs), and to resolve our inefficiencies around item count, we had to change the store schema. Specifically, we moved away from a per-database table structure to a per-mailbox table structure:
This architecture, along with other changes to the ESE and store engines (lazy view updates, space hints, page size increase, b+ tree defrag, etc.), netted us not only a 70% reduction in IO over Exchange 2007, but also substantially increased our ability to store more items in critical path folders.
As a result of the new architecture and the other changes to the store and ESE, we had to deal with an unintended side effect.  While these changes greatly improved our IO efficiency, they made our space efficiency worse.  In fact, on average they increased the size of the Exchange database by about 20% over Exchange 2007. To overcome this bloating effect, we implemented a targeted compression mechanism (using either 7-bit or XPRESS, which is the Microsoft implementation of the LZ77 algorithm) that specifically compresses message headers and bodies that are either text or HTML-based (attachments are not compressed as typically they exist in their most compressed state already).  The result of this work is that we see database sizes on par with Exchange 2007.
The below graph shows a comparison of database sizes for Exchange 2007 and Exchange 2010 with different types of message data:
As you can see, Exchange 2007 databases that contained 100% Rich Text Format (RTF) content was our baseline goal when implementing database compression in Exchange 2010. What we found is that with a mix of messaging data (77% HTML, 15% RTF, 8% Text, with an average message size of 50KB) that our compression algorithms are on par with Exchange 2007 database sizes. In other words, we mitigated most of the bloat caused by the lack of SIS.
Is compression the answer to replacing single instancing all together? The answer to that question is that it really does depend. There are certain scenarios where SIS may be viable:
  • Environments that only send Rich-Text Format messages. The compression algorithms in Exchange 2010 do not compress RTF message blobs because they already exist in their most compressible form.
  • Sending large attachments to many users. For example, sending a large (30 MB+) attachment to 20 users.  Even if there were only 5 recipients out of the 20 on the same database, in Exchange 2003 that meant the 30MB attachment was stored once instead of 5 times on that database. In Exchange 2010, that attachment is stored 5 times (150 MB for that database) and isn't compressed. But depending on your storage architecture, the capacity to handle this should be there. Also, your email retention requirements will help here, by forcing the removal of the data after a certain period of time.
  • Business or organizational archives that are used to maintain immutable copies of messaging data benefit from single instancing because the system only has to keep one copy of the data, which is useful when you need to maintain that data indefinitely for compliance purposes.
If you go back through our guidance over the past 10 years, you will never find a single reference to using SIS around capacity planning.  We might mention it has an impact in terms of the database size, but that's it.  All of our guidance has always dictated designing the storage without SIS in mind.  And for those that are thinking about thin provisioning, SIS isn't a reason to do thin provisioning, nor is SIS a means to calculate your space requirements.  Thin provisioning requires an operational maturity that can react quickly to changes in the messaging environment, as well as, a deep understanding of the how the user population behaves and grows over time to sufficiently allocate the right amount of storage upfront.
In summary, Exchange 2010 changes the messaging landscape.  The architectural changes we have implemented enable the commoditization of email - providing very large mailboxes at a low cost.  Disk capacity is no longer a premium.   Disk space is cheap and IT shops can take advantage of larger, cheaper disks to reduce their overall cost.  With Exchange 2010 you can deploy a highly available system with a degree of storage efficiency without SIS at a fraction of the cost that was required with previous versions of Exchange.
So, there you have it. SIS is gone.
 
 
Posted by at No comments:

Outlook Fonts change once you compose a new email or reply to an email

Issue:
 
Everytime once you compose a new email or reply to an email, Your Outlook's new message window shows very big or timy letters.
 
Cause:
 
If your font looks smaller or bigger than the actually configured font size, your zooming factor has been set above or below 100%.
 
Resolutions:
 
You can change it back in the following way:
 
Outlook 2010
When composing click on the Zoom button on the Home tab.
 
Outlook 2007

When composing go to the Format Text tab and click on the Zoom button.
 
 
Previous versions of Outlook
You can only zoom when you have Word set as the email editor. The Zoom function can be found in the View menu.
 
Note:
The change in the zoom factor probably was caused by holding the CTRL button while scrolling. This is an alternative method to change the zoom factor.
 
 
Posted by at No comments:

Wednesday, June 1, 2011

Outlook 2007 support for Exchange 2010 SP1 mailbox Archive

 
Outlook 2007 support for Personal Archives in Exchange 2010 SP1.
 
Exchange 2010 includes Personal Archives, a feature designed to help you reduce the risks from PST files and reduce the costs of discovery. Organizations can provision archive mailboxes for their users, allowing them to store older e-mail that's accessed less frequently in the archive. From the user's perspective, archive mailbox behaves like a PST file, minus the file management overhead and risks of a PST file. For more details, see Understanding Personal Archives in Exchange 2010 documentation. Also check out Exchange GM Perry Clarke's Geek Out With Perry series for a chalk talk video on Exchange Archiving.
In the Exchange 2010 RTM timeframe, users could use Outlook 2010 or Outlook Web App (OWA) to access archive mailboxes. This update extends archive support to Outlook 2007.

How does it work in Outlook 2007?

If an administrator provisions an archive mailbox for a user, it is accessible in Outlook 2007 with the December 2010 Cumulative Update installed. As with Outlook 2010, Outlook 2007 uses the Autodiscover service to obtain information about the user's archive mailbox. This occurs when the user starts Outlook, or at a fixed interval when Outlook is running. The archive mailbox is only accessible when the user is connected to the Exchange server.

Cached Exchange Mode and Archive Mailboxes

In Outlook 2010 and Outlook 2007, users can access archive mailboxes only when they're connected to the Exchange server. The connection can be an RPC (over TCP) connection, or Outlook Anywhere (aka RPC over HTTP). Even if the Outlook profile is configured to use Cached Exchange Mode, the archive mailbox is never cached locally to the user's computer. When the user is no longer connected to Exchange, the archive mailbox becomes inaccessible. The locally cached primary mailbox remains accessible if using Cached Exchange Mode.
Once the archive mailbox is visible in Outlook 2007, users can expand the folder hierarchy, and are able to perform the following operations:
  • Move or copy messages and folders between their primary mailbox and the archive mailbox
  • Move or copy messages and folders between a PST file and their archive mailbox (if access to PST files is not blocked by the administrator).
    Note: In Exchange 2010 SP1, administrators can also use mailbox import requests to import data from PST files to either the user's archive or primary mailbox. For more information, see Understanding Mailbox Import and Export Requests.
  • Export or import messages to and from the archive mailbox
  • Use Inbox Rules to automatically move messages to a folder in the archive mailbox
However, Outlook 2007 does not support the following functionality:
  • Search across primary and archive mailboxes: When a user searches the primary mailbox, and selects All Mailbox Items, Outlook does not search the archive mailbox. Similarly, when the user searches the archive mailbox, the primary mailbox is not searched.
  • Archive policies: In Outlook 2007, users can't use personal tags (also known as archive policies) to move items to the archive mailbox. Any default archive policies for the mailbox continue to be applied. Users can use Outlook Web App to see or apply archive policies.

    Archive policies are retention policy tags with the Move to Archive action. Organizations can use the Default Archive and Retention Policy, or apply custom retention policies to a mailbox. The policies can include a default policy tag (DPT) to move items from the primary mailbox to the archive mailbox, and personal tags which users can apply to messages or folders to move them to archive. For more information, see Understanding Personal Archives, and Understanding Retention Tags and Retention Policies.
With the release of this update, organizations with Office 2007/Outlook 2007 deployed can benefit from Exchange 2010's archiving and retention features.
Posted by at No comments:
Subscribe to: Posts (Atom)