This article explains the features of the exchange management shell EMS. Unlike the previous version of the exchange, the exchange server 2007 has this new feature of accomplishing all the exchange related activity in the command shell. The PowerShell uses the cmdlets as a core technology. A cmdlet is a lightweight command that is used in the PowerShell and Exchange Management Shell environments. Within that environment, the PowerShell command interpreter (PS.exe) executes these cmdlets within the context of automation scripts. The .NET framework is the core package which executes the PowerShell. Nearly 350 exchange related cmdlets are available in the EMS. The EMS works in the back end of the exchange management console.
Uses of EMS:
1. EMS main usage is to perform the administrative functions such as Mailbox management, setting limits for users, Moving mailbox b/w servers, configuring the exchange related parameters, etc.
2. EMS also helps in generating the reports such as recipient details, messaging routing traffic, message size distributions, etc.
General Syntax of the PowerShell Commands:
#Verb-Noun format. The PowerShell commands are auto-tab complete.
Eg., Move-Mailbox, Get-Mailbox, etc.
The commands in the PowerShell can be chained using the pipe option.
Interpreting the PowerShell Commands:
In order to move the mailbox to other server,
In General, Move the Mailbox of the user Stephen to the Mailbox Store2. This can be put syntactically
#Move-Mailbox “Mcgrorty, Stephen” –Targetdatabase “Mailbox Store 2”
Help Option in the EMS:
1. #Get-Help command
2. #Get-Help Set-Mailbox –Parameter *quota*
3. #Get-Help -Role *Mailbox*
Eg, Get-mailboxpermission,Get-mailboxdatabase,etc.
4. #Get-Help -Role *Mailbox* | fl name, synopsis
5. #Get-Help -Component *Recipient*
Eg, Get-mailbox,get-mailboxstatistics,etc.
6. #Get-Help -Functionality *Server*
Eg, Get-mailboxserver,Get-sendconnector,etc.
Pipeline Option:
To move all mailbox in the server1 to the server2
#Get-Mailbox –server server1 | Move-Mailbox –targetdatabase “server2\Mailbox Store1”
To set the maximum send size attribute for the recipient “Andreo Nel”
#Get-Mailbox | where-object { $_.name –like “And*” } | Set-Mailbox –MaxSendSize 10mb
WhatIf and Confirm Option:
To move the mailbox with the name “sandy” to the server2. The –WhatIf parameter informs the administrator what action the script would take and the –Confirm parameter prompts for confirmation before taking action.
#Get-Mailbox | where-object { $_.name –like “sandy*” } | Move-Mailbox –targetdatabase “Server2\Mailbox Store1” –WhatIf
Sample Output:
What if: Performing operation “move-Mailbox” on Target “Move mailbox for:Administrator (Administrator@companyabc.com) to Database: Mailbox Database 2,09014bc6-f977-4961-b4eb-8829fb13e5d6. The operation can take a long time and the mailbox will be inaccessible until the move is complete”.
#Get-Mailbox | where-object { $_.name –like “sandy*” } | Move-Mailbox –targetdatabase “Server2\Mailbox Store1” –Confirm
Sample Output:
Are you sure you want to perform this action? Performing operation “move-Mailbox” on Target “Move mailbox for: Administrator (Administrator@companyabc.com) to Database: Mailbox Database 1,09014bc6-f977-4961-b4eb-8829fb13e5d6. The operation can take a long time and the mailbox will be inaccessible until the move is complete”. [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is “Y”):
Some Important and Useful PowerShell Commands In exchange server 2007:
1. To create a new mail database in the first storage group on server2.
#New-MailboxDatabase –StorageGroup “SERVER2\First Storage Group” –name “Mailbox Store2”
2. To mount the above database,
#Mount-database “SERVER2\First Storage Group\Mailbox Store2”
3. To test the connectivity of the recipient mailbox and also to check the latency.
#Test-MapiConnectivity testuser@company.com
4. To get the list of mailbox with the maximum mailbox size,
#Get-wmiobject -class Exchange_Mailbox -Namespace ROOT\MicrosoftExchangev2 -ComputerName SERVER1 | select-object MailboxDisplayName,TotalItems,Size | sort -descending “Size” | select-object -first 25
5. The above can also be viewed in the HTML format and also can be directed to some file. This makes it portable.
#Get-wmiobject -class Exchange_Mailbox -Namespace ROOT\MicrosoftExchangev2 -ComputerName SERVER1 | select-object MailboxDisplayName,TotalItems,Size | sort -descending “Size” | select-object -first 25 | ConvertTo-html -title “Top 25 Largest Mailboxes on SERVER1” > “D:\Stats\25 Largest Mailboxes.html”
6. To get the events in the application log with the source starting with the word “Exchange” ,
#get-eventlog Application | where {$_.Source -ilike “Exchange*”} | export-csv c:\events.csv
7. To get the information of particular user mailbox
# Get-Mailbox –Identity "Rudi Kutz"
#Get-Mailbox "Rudi Kutz"
#Get-Mailbox rudi.kutz@philips.com
8. To get the list of exchange servers in the organization,
#Get-ExchangeServer
#Get-ExchangeServer -Domain loguinfo.com
#Get-ExchangeServer –Status
9. To get the mailbox database details,
# Get-MailboxDatabase -Server Server
#Get-MailboxDatabase -StorageGroup StorageGroup
10. To set the quota limit parameter for particular database,
# Set-MailboxDatabase -Identity MailboxDatabase -IssueWarningQuota 500MB
11. To set the user’s mailbox properties like external Email Email address value,
# Set-MailUser -Identity user2 -ExternalEmailAddress test@external.com
12. To get all the records which matching the namespace “logu”, it check in all the possible recipients like user mailbox, contacts, etc.
# Get-Recipient -Anr "logu"
13. To Enable/Disable the user,
# Disable-MailUser -Identity user2
# Enable-Mailbox -Identity company\user1 -Database MailboxDatabase
14. To get the mailbox statistics of the database,
# Get-MailboxStatistics -Database MailboxDatabase
#Get-MailboxStatistics -Server Server
15. To give full access permission for the user1 on the mailbox user2,
#Add-MailboxPermission user2 -User user1 -AccessRights FullAccess
16. The same case if it is a linked mailbox (external mail account which has mailbox in this server),
#Add-MailboxPermission user2 -user CODE1\user1 -AccessRights:FullAccess,ExternalAccount
Saturday, December 26, 2009
Friday, December 25, 2009
Duplicate emails getting in the outlook
Most of the Outlook users would have faced the problem of getting duplicate emails or calendar entries. In this article, I have listed down the possible reason for getting the duplicate entries.
There can be many reasons why a user would see multiple messages in their mailboxes. The most likely ones are outlined here.
1. The message has actually been sent more than once by the originator. Check the date in the "Date:" clause. If the dates are different, then the message was sent by the originator more than once.
2. The user is an alias of another account and both accounts received a copy of the mail. To see if this has occurred, open both messages and view the complete header. Look at the last "Received:" clause. This clause will say who the message saw sent to. If there are different addresses, then this explains why the message appeared twice.
3. The user gets mail forwarded from another account and both accounts received a copy of the message. Use the same check as above to see if this is the case.
4. One mail server between the sender and recipient is (incorrectly) duplicating the message. To see if this has occurred, open both messages and view the complete header. Match each of the "Received:" clauses until you find two that are different. These two received clauses will give a different time for the receipt of the message. This clause identifies the server that is duplicating email messages. You will need to contact the owner of the server for further investigation.
Other items to help determine the cause of the duplicate messages appearing include taking a look in the headers of the messages themselves. The topmost Received header will contain a unique ID for the message consisting of 8 characters.
You can then take a look in the SMTP log for the server and search for this unique ID. This will show you the exact SMTP transaction that caused the message to enter your server. You will be able to see exactly which users the message was delivered to.
If the unique ID's are different then the messages are the result of more than one transaction. Likely reason being that the message was delivered to the server more than once. Again this can be confirmed from the logs.
When trying to debug these issues it is helpful if you enable all of the logging options for the SMTP service.
Reasons why you might see a message being sent more than once can include
1. Misconfiguration of the sending server
2. High CPU usage on your server for extended periods of time, causing connections to time out and thus the remote server retries the message again.
3. Malformed content being sent by the remote server
If you use the Anti-spam option to scan content for restricted words and do not limit the scanning to a certain number of lines, you are likely to see periods of high CPU usage on your server, particularly if you frequently process messages containing large attachments.
There can be many reasons why a user would see multiple messages in their mailboxes. The most likely ones are outlined here.
1. The message has actually been sent more than once by the originator. Check the date in the "Date:" clause. If the dates are different, then the message was sent by the originator more than once.
2. The user is an alias of another account and both accounts received a copy of the mail. To see if this has occurred, open both messages and view the complete header. Look at the last "Received:" clause. This clause will say who the message saw sent to. If there are different addresses, then this explains why the message appeared twice.
3. The user gets mail forwarded from another account and both accounts received a copy of the message. Use the same check as above to see if this is the case.
4. One mail server between the sender and recipient is (incorrectly) duplicating the message. To see if this has occurred, open both messages and view the complete header. Match each of the "Received:" clauses until you find two that are different. These two received clauses will give a different time for the receipt of the message. This clause identifies the server that is duplicating email messages. You will need to contact the owner of the server for further investigation.
Other items to help determine the cause of the duplicate messages appearing include taking a look in the headers of the messages themselves. The topmost Received header will contain a unique ID for the message consisting of 8 characters.
You can then take a look in the SMTP log for the server and search for this unique ID. This will show you the exact SMTP transaction that caused the message to enter your server. You will be able to see exactly which users the message was delivered to.
If the unique ID's are different then the messages are the result of more than one transaction. Likely reason being that the message was delivered to the server more than once. Again this can be confirmed from the logs.
When trying to debug these issues it is helpful if you enable all of the logging options for the SMTP service.
Reasons why you might see a message being sent more than once can include
1. Misconfiguration of the sending server
2. High CPU usage on your server for extended periods of time, causing connections to time out and thus the remote server retries the message again.
3. Malformed content being sent by the remote server
If you use the Anti-spam option to scan content for restricted words and do not limit the scanning to a certain number of lines, you are likely to see periods of high CPU usage on your server, particularly if you frequently process messages containing large attachments.
Functionality System Mailbox in exchange server 2003
This article gives you the functionality of the built in system mailbox that present in the mailbox store. Every private information store in Exchange Server 2003, has 3 system mailbox by default.
The following are the three different system mailboxes are:
•SystemMailbox{GUID}
•System Attendant Mailbox
•SMTP Mailbox
System Mailbox {GUID}:
•Contains two parts to each System mailbox – the mailbox itself with its content in the corresponding information store and an associated directory object located in MESO (Microsoft Exchange System Object) folder in AD.
•GUID is related to the objectGUID i.e., to the system mailbox. The objectGUID of the mailbox store with which the system mailbox is associated.
•Whenever we mount the store, it checks for the availability of the systemmailbox{GUID}. If not it looks in the MESO directory for the same.
•Each MDB has its own GUID associated with a particular instance of SystemMailbox{guid}.
•Faulty functioning SystemMailbox{guid} then, there’s a very good chance EXOLEDB event sinks will not function.
•It will occupy some reasonable amt of space for storing the schema definitions.
System Attendant Mailbox:
•Each Exchange 200x server has one (and hopefully only one) System Attendant mailbox
•The System Attendant Mailbox contains the folder SpecialPrivateFolderForFreeBusyStorage, for Free/Busy information for Microsoft Outlook and CDO Applications (Collaboration Data Objects) which will be temporarily stored in MSExchangeFBPublish.
•The System Attendant Mailbox will also be used to send and receive Exchange monitoring messages for the Link Monitoring Service. You can find this function in the Exchange System Manager under Tools – Monitoring and Status.
•System Attendant mailbox is also required to be available during mailbox moves. For instance, if you have the mailbox store containing the System Attendant mailbox dismounted during a mailbox move, the move will fail.
•There are two parts to make up the complete System Attendant mailbox: a directory object and a mailbox object.
•Faulty system attendant mailbox, results in OWA-generated Free/Busy information not getting updated and also mailbox moves fail.
SMTP Mailbox
•The SMTP mailbox will be generated when the private information store is created and mounted.
•SMTP (servername-{guid}) mailbox is used by the mail transport of Exchange 200x as a temporary holding place for various messages as they pass through the system. In other words, every private mailbox store contains an SMTP mailbox to store temporary messages.
•For eg, The folders MTS-IN and MTS-OUT are used by Exchange Deployment Kit (EDK) connectors to transfer messages between the MTA (Microsoft Exchange Transport Agent) and the Exchange Server information store (store.exe). They are also used for X400 connectors, Exchange site connectors, and fax connectors.
•Faulty SMTP mailbox, results in failure in delivery into the store
Logging into system mailbox:
Logging into the system mailbox is not recommended, but still we can open the mailbox using the MFCMAPI.
The following are the three different system mailboxes are:
•SystemMailbox{GUID}
•System Attendant Mailbox
•SMTP Mailbox
System Mailbox {GUID}:
•Contains two parts to each System mailbox – the mailbox itself with its content in the corresponding information store and an associated directory object located in MESO (Microsoft Exchange System Object) folder in AD.
•GUID is related to the objectGUID i.e., to the system mailbox. The objectGUID of the mailbox store with which the system mailbox is associated.
•Whenever we mount the store, it checks for the availability of the systemmailbox{GUID}. If not it looks in the MESO directory for the same.
•Each MDB has its own GUID associated with a particular instance of SystemMailbox{guid}.
•Faulty functioning SystemMailbox{guid} then, there’s a very good chance EXOLEDB event sinks will not function.
•It will occupy some reasonable amt of space for storing the schema definitions.
System Attendant Mailbox:
•Each Exchange 200x server has one (and hopefully only one) System Attendant mailbox
•The System Attendant Mailbox contains the folder SpecialPrivateFolderForFreeBusyStorage, for Free/Busy information for Microsoft Outlook and CDO Applications (Collaboration Data Objects) which will be temporarily stored in MSExchangeFBPublish.
•The System Attendant Mailbox will also be used to send and receive Exchange monitoring messages for the Link Monitoring Service. You can find this function in the Exchange System Manager under Tools – Monitoring and Status.
•System Attendant mailbox is also required to be available during mailbox moves. For instance, if you have the mailbox store containing the System Attendant mailbox dismounted during a mailbox move, the move will fail.
•There are two parts to make up the complete System Attendant mailbox: a directory object and a mailbox object.
•Faulty system attendant mailbox, results in OWA-generated Free/Busy information not getting updated and also mailbox moves fail.
SMTP Mailbox
•The SMTP mailbox will be generated when the private information store is created and mounted.
•SMTP (servername-{guid}) mailbox is used by the mail transport of Exchange 200x as a temporary holding place for various messages as they pass through the system. In other words, every private mailbox store contains an SMTP mailbox to store temporary messages.
•For eg, The folders MTS-IN and MTS-OUT are used by Exchange Deployment Kit (EDK) connectors to transfer messages between the MTA (Microsoft Exchange Transport Agent) and the Exchange Server information store (store.exe). They are also used for X400 connectors, Exchange site connectors, and fax connectors.
•Faulty SMTP mailbox, results in failure in delivery into the store
Logging into system mailbox:
Logging into the system mailbox is not recommended, but still we can open the mailbox using the MFCMAPI.
Wednesday, December 23, 2009
Role of Expansion Server
This article explains the function and role of expansion server in the exchange server 2003.
1. Expansion server generally routes the message that are sent to a single distribution list or group of users listed in that group.
2. It is also responsible for expanding the group to its individual members and also will resolves the name of the recipients.
3. Importantly it is used to determine the most efficient path for routing the messages.
4. To find the expansion server for a distribution group, Right click the distribution group àproperties à Exchange advanced à Expansion server à click the drop down button to list.
5. In detail,
a. When user selects group from GAL in outlook. The outlook obtains the GAL via NSPI(Name Service Provider Interface) request sent to a GC.
b. Once the name verification succeeds, it will turn the recipient address bold.
c. When user sends, outlook uses MAPI to transmit the message to the user’s home exchange server.
d. Exchange server sees that the recipient is a group, and it sends an LDAP query to GC for the member’s list along with the email attributes.
6. By default any server can in the exchange organization can acts as a expansion server. This option is recommended because it totally avoids the single point of failure. Assigning particular server as a expansion server for particular group will result in failure if that particular server is unavailable.
1. Expansion server generally routes the message that are sent to a single distribution list or group of users listed in that group.
2. It is also responsible for expanding the group to its individual members and also will resolves the name of the recipients.
3. Importantly it is used to determine the most efficient path for routing the messages.
4. To find the expansion server for a distribution group, Right click the distribution group àproperties à Exchange advanced à Expansion server à click the drop down button to list.
5. In detail,
a. When user selects group from GAL in outlook. The outlook obtains the GAL via NSPI(Name Service Provider Interface) request sent to a GC.
b. Once the name verification succeeds, it will turn the recipient address bold.
c. When user sends, outlook uses MAPI to transmit the message to the user’s home exchange server.
d. Exchange server sees that the recipient is a group, and it sends an LDAP query to GC for the member’s list along with the email attributes.
6. By default any server can in the exchange organization can acts as a expansion server. This option is recommended because it totally avoids the single point of failure. Assigning particular server as a expansion server for particular group will result in failure if that particular server is unavailable.
Monday, December 21, 2009
Difference between BIS and BES
BIS – (For individuals and small businesses)
The BlackBerry Internet Solution provides a wireless solution tailored to meet the needs of individual users and small and medium-sized businesses (SMB). The BlackBerry Internet Service, a component of the BlackBerry Internet Solution, allows wireless connectivity to Internet-based email and other applications. The architecture for BlackBerry Internet Service,
including Internet browsing functionality, is shown in the diagram below: BlackBerry Internet Service leverages centrally hosted wireless gateways, allowing users to access up to 10 supported email accounts and Internet browsing functionality* without the need to install and manage a BlackBerry Enterprise Server.
BES
The BlackBerry Enterprise Solution allows the wireless extension of corporate email and applications with the BlackBerry Enterprise Server™, an important component of the solution, and would be managed by the organisations own internal I.T. department. The typical architecture of the BlackBerry Enterprise Solution is shown in the diagram below: The BlackBerry Enterprise Server is installed and managed behind the corporate firewall and includes integrated support for extending corporate messaging solutions, including Microsoft Exchange, IBM Lotus Domino and Novell GroupWise. The BlackBerry Enterprise Server also acts as a wireless gateway allowing the BlackBerry Browser and custom applications on the BlackBerry device to connect to corporate applications and web servers, as well as to Internet-based web servers.
The BlackBerry Internet Solution provides a wireless solution tailored to meet the needs of individual users and small and medium-sized businesses (SMB). The BlackBerry Internet Service, a component of the BlackBerry Internet Solution, allows wireless connectivity to Internet-based email and other applications. The architecture for BlackBerry Internet Service,
including Internet browsing functionality, is shown in the diagram below: BlackBerry Internet Service leverages centrally hosted wireless gateways, allowing users to access up to 10 supported email accounts and Internet browsing functionality* without the need to install and manage a BlackBerry Enterprise Server.
BES
The BlackBerry Enterprise Solution allows the wireless extension of corporate email and applications with the BlackBerry Enterprise Server™, an important component of the solution, and would be managed by the organisations own internal I.T. department. The typical architecture of the BlackBerry Enterprise Solution is shown in the diagram below: The BlackBerry Enterprise Server is installed and managed behind the corporate firewall and includes integrated support for extending corporate messaging solutions, including Microsoft Exchange, IBM Lotus Domino and Novell GroupWise. The BlackBerry Enterprise Server also acts as a wireless gateway allowing the BlackBerry Browser and custom applications on the BlackBerry device to connect to corporate applications and web servers, as well as to Internet-based web servers.
Sunday, December 20, 2009
Migrating from Antigen 8.0 for Exchange to Antigen 9.0 for Exchange
Because Antigen 8 for Exchange and Antigen 8 for SMTP Gateways are reaching their “End of Life” date on December 31, 2009, you will need to migrate to Antigen 9 or the appropriate Forefront product if you are currently running either of these products.
Additionally, the Antigen 8 for IM and Antigen 8 for SharePoint products will also eventually reach their own End of Life dates, and you will also have to migrate off of these products and onto supported versions.
The recommended procedures for migrating from Antigen 8 products to Antigen 9 or Forefront products are provided in this article.
Migrating from Antigen 8.0 for Exchange to Antigen 9.0 for Exchange:
You may upgrade Antigen 8 for Exchange to Antigen 9 for Exchange in one of two ways – by using a management tool (the Antigen Central Manager [ACM]) or by performing the upgrade locally on the Exchange server.
Note: You must be running Exchange 2000 or 2003 to upgrade from Antigen 8.0 to Antigen 9.0. If you are running Exchange 5.5 you must first uninstall Antigen 8.0, upgrade Exchange to 2000 or 2003 following Microsoft Exchange upgrade procedures, and then install Antigen 9.0.
To upgrade Sybari Antigen 8.0 SR3 to Microsoft Antigen 9.0 using a management tool, follow these steps:
1. Download the Antigen 9.0 installation package, and save it to a temporary folder.
2. Double-click the Antigen 9.0 installation package to extract the files.
3. Open the Antigen Central Manager.
4. On the Jobs menu, click Default Options.
5. In the Global Settings dialog box, enter the source folder name, add the location of the files that you have extracted in step 2, and click OK.
6. On the Jobs menu, click Create Job.
7. In the Task box, click to select Install.
8. Click Add to add the Antigen 8.0 SR3 server that you want to upgrade to Antigen 9.0.
9. Click Options to open the Installation Options dialog box.
10. Verify the information.
11. Click OK to close the Installation Options dialog box.
12. Click OK to close the Create Job dialog box.
13. Select the installation job that you created, and click the green arrow to start the job.
14. When the install has completed successfully, the following message will appear under Status in the ACM – “The job has completed successfully.”
To upgrade Sybari Antigen 8.0 SR3 to Microsoft Antigen 9.0 locally, simply double click the Antigen 9 for Exchange Setup.exe that you have previously downloaded from the Microsoft Volume License Site and following the prompts in the install.
For more information about the Antigen 9.0 for Exchange install, see Chapter 2 - Installing Microsoft Antigen for Exchange in the Antigen for Exchange User Guide found here:
Migrating from Antigen 8.0 for Exchange to FSE:
Since FSE is only supported on Exchange 2007, you must first uninstall Antigen 8.0 for Exchange, upgrade your Exchange 2000 or 20003 installation to Exchange 2007 following the Exchange 2007 product documentation, and then perform a fresh installation of FSE.
- To uninstall Antigen 8.0 for Exchange, stop all Antigen and Exchange services in the Service Control Manager and then click Remove in Add/Remove Programs. Follow the prompts to remove the product, and then delete the Antigen for Exchange installation folder (default path of Program Files\Sybari Software\Antigen for Exchange).
- To upgrade Exchange 2000 or 2003 to Exchange 2007, follow the recommended upgrade procedure outlined the Exchange 2007 product documentation.
Migrating from Antigen 8.0 for IM to Forefront Security for Office Communications Server (FSOCS):
As there are no Antigen 9 products for IM, you must first uninstall your Antigen 8 product, then upgrade your existing IM installation to one of the supported versions, and then perform a fresh install of FSOCS.
· To uninstall Antigen 8.0 for IM, stop all Antigen services in the Service Control Manager and then click Remove in Add/Remove Programs. Follow the prompts to remove the product, and then delete the Antigen for IM installation folder (default path of Program Files\Sybari Software\Antigen for IM).
· To upgrade Microsoft Live Communications Server 2003 or Microsoft Live Communications Server 2005 to Microsoft Office Communications Server 2007 or Microsoft Office Communications Server 2007 R2, follow the recommended upgrade procedure outlined the OCS product documentation.
Additionally, the Antigen 8 for IM and Antigen 8 for SharePoint products will also eventually reach their own End of Life dates, and you will also have to migrate off of these products and onto supported versions.
The recommended procedures for migrating from Antigen 8 products to Antigen 9 or Forefront products are provided in this article.
Migrating from Antigen 8.0 for Exchange to Antigen 9.0 for Exchange:
You may upgrade Antigen 8 for Exchange to Antigen 9 for Exchange in one of two ways – by using a management tool (the Antigen Central Manager [ACM]) or by performing the upgrade locally on the Exchange server.
Note: You must be running Exchange 2000 or 2003 to upgrade from Antigen 8.0 to Antigen 9.0. If you are running Exchange 5.5 you must first uninstall Antigen 8.0, upgrade Exchange to 2000 or 2003 following Microsoft Exchange upgrade procedures, and then install Antigen 9.0.
To upgrade Sybari Antigen 8.0 SR3 to Microsoft Antigen 9.0 using a management tool, follow these steps:
1. Download the Antigen 9.0 installation package, and save it to a temporary folder.
2. Double-click the Antigen 9.0 installation package to extract the files.
3. Open the Antigen Central Manager.
4. On the Jobs menu, click Default Options.
5. In the Global Settings dialog box, enter the source folder name, add the location of the files that you have extracted in step 2, and click OK.
6. On the Jobs menu, click Create Job.
7. In the Task box, click to select Install.
8. Click Add to add the Antigen 8.0 SR3 server that you want to upgrade to Antigen 9.0.
9. Click Options to open the Installation Options dialog box.
10. Verify the information.
11. Click OK to close the Installation Options dialog box.
12. Click OK to close the Create Job dialog box.
13. Select the installation job that you created, and click the green arrow to start the job.
14. When the install has completed successfully, the following message will appear under Status in the ACM – “The job has completed successfully.”
To upgrade Sybari Antigen 8.0 SR3 to Microsoft Antigen 9.0 locally, simply double click the Antigen 9 for Exchange Setup.exe that you have previously downloaded from the Microsoft Volume License Site and following the prompts in the install.
For more information about the Antigen 9.0 for Exchange install, see Chapter 2 - Installing Microsoft Antigen for Exchange in the Antigen for Exchange User Guide found here:
Migrating from Antigen 8.0 for Exchange to FSE:
Since FSE is only supported on Exchange 2007, you must first uninstall Antigen 8.0 for Exchange, upgrade your Exchange 2000 or 20003 installation to Exchange 2007 following the Exchange 2007 product documentation, and then perform a fresh installation of FSE.
- To uninstall Antigen 8.0 for Exchange, stop all Antigen and Exchange services in the Service Control Manager and then click Remove in Add/Remove Programs. Follow the prompts to remove the product, and then delete the Antigen for Exchange installation folder (default path of Program Files\Sybari Software\Antigen for Exchange).
- To upgrade Exchange 2000 or 2003 to Exchange 2007, follow the recommended upgrade procedure outlined the Exchange 2007 product documentation.
Migrating from Antigen 8.0 for IM to Forefront Security for Office Communications Server (FSOCS):
As there are no Antigen 9 products for IM, you must first uninstall your Antigen 8 product, then upgrade your existing IM installation to one of the supported versions, and then perform a fresh install of FSOCS.
· To uninstall Antigen 8.0 for IM, stop all Antigen services in the Service Control Manager and then click Remove in Add/Remove Programs. Follow the prompts to remove the product, and then delete the Antigen for IM installation folder (default path of Program Files\Sybari Software\Antigen for IM).
· To upgrade Microsoft Live Communications Server 2003 or Microsoft Live Communications Server 2005 to Microsoft Office Communications Server 2007 or Microsoft Office Communications Server 2007 R2, follow the recommended upgrade procedure outlined the OCS product documentation.
Thursday, December 17, 2009
Unified Communications, Unified Messaging and Voice Mail
Unified Messaging (UM) is itself a rather nebulous term. Everyone seems to agree on some of the characteristics of UM. Voice mail and e-mail are presented together, visually, to the user in their mail client. There is an over-the-phone interface to allow messages to be listened to, replied to and deleted. Beyond that, there is little consensus. Should all messages be contained in a common store? Should fax be supported, and how? How is identity managed? And so on.
I'm happy to talk about Microsoft Exchange Unified Messaging as "UM". It's the product I work on, and it's the product I use every day. So, as long as I'm careful to say "Exchange UM" when there is any danger of confusion, I can clarify the underlying principles and describe the features when I'm asked about it.
Exchange UM is packaged as one of the server roles in Exchange 2010. (It was introduced in Exchange 2007). It has three main feature areas:
Voice Mail. The basic call-answering functionality. If a user does not answer a call to their phone, the call is eventually forwarded to a UM server. It answers, and plays the user's greeting, such as: "Hello, this is Michael. I'm sorry I can't take your call. Please leave a message." The caller then hears a BEEP and records their message for the user. UM arranges for the message to be delivered to the user's Exchange Inbox. The user can listen to the message by using a mail client such as Outlook or Exchange 2010 Outlook Web App (OWA), or by using...
Outlook Voice Access. This provides a telephone interface to Exchange that works for any phone. A user calls a number that is answered by UM; they identify themselves to the system with a sequence of touch tone keys. UM then tells them what's new, for example: "You have 2 new voice messages and 8 new e-mails..." What sets UM apart from older voice mail and unified messaging systems is that users are able to access not only voice mail and e-mail over the phone, but can also access their calendar, and call or send voice messages to Personal Contacts or other users. And they can do this with voice commands, because speech recognition is enabled in all of Exchange 2010 UM's 26 language packs.
Automated Attendant. Many companies want to provide telephone callers with a convenient way of reaching their employees, even if the caller doesn't know the employee's telephone number, but only the company's main "switchboard" number. An Automated Attendant is a system that answers the phone in such a case, prompts the caller, collects their input and tries to direct their call to the correct person. Automated Attendants are sometimes chained together to make multi-level menus. Exchange UM allows the Automated Attendants to be speech-enabled, so that the caller can simply say the name of the person that they want to contact.
The architecture that underpins Exchange UM is true to the "Unified" name. All messages are stored in Microsoft Exchange. All messages are transported by Microsoft Exchange. All identities (and the vast majority of configuration details) are managed by Microsoft Windows and Active Directory. Administrators who already know Exchange will find a few new concepts in UM, but they all relate to its connection to the world of telephony. Much of UM will seem very comfortable to the Exchange administrator.
I'm happy to talk about Microsoft Exchange Unified Messaging as "UM". It's the product I work on, and it's the product I use every day. So, as long as I'm careful to say "Exchange UM" when there is any danger of confusion, I can clarify the underlying principles and describe the features when I'm asked about it.
Exchange UM is packaged as one of the server roles in Exchange 2010. (It was introduced in Exchange 2007). It has three main feature areas:
Voice Mail. The basic call-answering functionality. If a user does not answer a call to their phone, the call is eventually forwarded to a UM server. It answers, and plays the user's greeting, such as: "Hello, this is Michael. I'm sorry I can't take your call. Please leave a message." The caller then hears a BEEP and records their message for the user. UM arranges for the message to be delivered to the user's Exchange Inbox. The user can listen to the message by using a mail client such as Outlook or Exchange 2010 Outlook Web App (OWA), or by using...
Outlook Voice Access. This provides a telephone interface to Exchange that works for any phone. A user calls a number that is answered by UM; they identify themselves to the system with a sequence of touch tone keys. UM then tells them what's new, for example: "You have 2 new voice messages and 8 new e-mails..." What sets UM apart from older voice mail and unified messaging systems is that users are able to access not only voice mail and e-mail over the phone, but can also access their calendar, and call or send voice messages to Personal Contacts or other users. And they can do this with voice commands, because speech recognition is enabled in all of Exchange 2010 UM's 26 language packs.
Automated Attendant. Many companies want to provide telephone callers with a convenient way of reaching their employees, even if the caller doesn't know the employee's telephone number, but only the company's main "switchboard" number. An Automated Attendant is a system that answers the phone in such a case, prompts the caller, collects their input and tries to direct their call to the correct person. Automated Attendants are sometimes chained together to make multi-level menus. Exchange UM allows the Automated Attendants to be speech-enabled, so that the caller can simply say the name of the person that they want to contact.
The architecture that underpins Exchange UM is true to the "Unified" name. All messages are stored in Microsoft Exchange. All messages are transported by Microsoft Exchange. All identities (and the vast majority of configuration details) are managed by Microsoft Windows and Active Directory. Administrators who already know Exchange will find a few new concepts in UM, but they all relate to its connection to the world of telephony. Much of UM will seem very comfortable to the Exchange administrator.
Friday, December 4, 2009
Exchange 2010 database availability group (DAG)
What is a DAG?
A database availability group (DAG) is the base component of the high availability and site resilience framework that is built into Exchange 2010. A DAG is a group of up to 16 Mailbox servers that host a set of databases and provide automatic database-level recovery from failures that affect individual servers or databases. Exchange 2010 uses the same continuous replication technology found in Exchange 2007. Exchange 2010 combines on-site data replication (CCR) and off-site data replication (SCR) into a single framework which is the DAG. Once servers have been added to a DAG, administrators can add replicated database copies incrementally, and Exchange 2010 switches between these copies automatically, as needed, to maintain availability.
When can I create a DAG?
After you've deployed Exchange 2010, you can create a DAG, add Mailbox servers to the DAG, and then replicate mailbox databases between the DAG members. A DAG can be created using the New Database Availability Group wizard in the Exchange Management Console, or by running the New-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. When creating a DAG, you provide a name for the DAG, and optional witness server and witness directory settings. In addition, one or more IP addresses are assigned to the DAG, either by using static IP addresses or by allowing the DAG to be automatically assigned the necessary IP addresses using Dynamic Host Configuration Protocol (DHCP).
Do I need to setup windows cluster for the DAG to work?
No, there is nothing called a standalone or clustered Exchange 2010 installation. After you install a normal Exchange 2010 mailbox server, you need to run the New-DatabaseAvailabilityGroup cmdlet to create a DAG, once the DAG has been created, mailbox servers can be added to the DAG. When the first server is added to the DAG, a cluster is formed for use by the DAG. DAGs make limited use of Windows Failover Clustering technology, namely the cluster heartbeat, cluster networks, and the cluster database (for storing data that changes or can change quickly, such as database state changes from active to passive or vice versa, or from mounted to dismounted and vice versa). As each subsequent server is added to the DAG, it is joined to the underlying cluster (and the cluster's quorum model is automatically adjusted by the system, as needed), and the server is added to the DAG object in Active Directory. And because DAGs rely on Windows Failover Clustering, they can only be created on Exchange 2010 Mailbox servers that are running Windows Server 2008 Enterprise Edition or Windows Server 2008 R2 Enterprise Edition. In addition, each Mailbox server in the DAG must have at least two network interface cards in order to be supported
What's happening when I create a DAG or join a server to an existing DAG?
When the first Mailbox server is added to a DAG, the following occurs:
- The Windows Failover Clustering component is installed, if it is not already installed.
- A failover cluster is created using the name of the DAG.
- A cluster network object (CNO) is created in default computers container.
- The name and IP address of the DAG is registered as a Host (A) record in DNS.
- The server is added to DAG object in Active Directory.
- The cluster database is updated with information on the databases that are mounted on the added server.
When the second and subsequent servers are added to the DAG, the following occurs:
- The server is joined to Windows Failover Cluster for the DAG.
- The quorum model is automatically adjusted:
- A Node Majority quorum model is used for DAGs with an odd number of members.
- A Node and File Share Majority quorum is used for DAGs with an even number of members.
- The witness directory and share are automatically created by Exchange when needed.
- The server is added to DAG object in Active Directory.
- The cluster database is updated with info on mounted databases
Can I have DAG members from different subnets?
Yes, during the cluster creation, the Add-DatabaseAvailabilityGroupServer task retrieves the IP address(es) configured while you are creating the DAG, takes whatever appropriate IP and ignores the ones don't match any of the subnets found on the server. This gives you the flexibility to have a DAG with members on the same or different subnets "in case you will have a DAG node in another datacenter".
Can I use a 3rd party replication tool to replicate the databases in the DAG?
By default, a DAG is designed to use the built-in continuous replication feature to replicate mailbox databases between servers in the DAG. If you are using third-party data replication that supports the Third Party Replication API in Exchange 2010, you must create the DAG in third party replication mode by using the New-DatabaseAvailabilityGroup cmdlet with the ThirdPartyReplication parameter, but note that Once this mode is enabled, it cannot be disabled.
Can I encrypt the DAG network traffic?
DAGs support the use of encryption by leveraging the encryption capabilities of the Windows Server operating system. DAGs use Kerberos authentication between Exchange servers. Microsoft Kerberos SSP’s EncryptMessage/DecryptMessage APIs handle encryption of DAG network traffic. Microsoft Kerberos SSP supports multiple encryption algorithms. The Kerberos authentication handshake picks the strongest encryption protocol supported in the list: typically AES 256-bit, potentially with a SHA Hash Message Authentication Code (HMAC) to maintain integrity of the data
Can I compress the DAG network communication?
DAGs also support built-in compression. When compression is enabled, DAG network communication uses XPRESS, which is Microsoft’s implementation of the LZ77 algorithm. This is the same type of compression used in many Microsoft protocols, in particular, MAPI RPC compression between Outlook and Exchange
What is the minimum network interfaces required for a DAG?
As indicated above, each Mailbox server in the DAG must have at least two network interface cards in order to be supported. In Exchange 2010, DAGs primarily have two types of networks: MAPI networks, which are used by other Exchange 2010 servers to communicate with the Mailbox server in the DAG, and Replication networks, which are used for log shipping and seeding within the DAG. So the reason to have at least two NICs is that this configuration enables you to configure one MAPI network and one Replication network.
What will happen if one of my DAG networks encountered a failure?
In the event of a failure affecting the MAPI network, a server failover will occur (assuming there are healthy mailbox database copies that can be activated). In the event of a failure affecting the Replication network, if the MAPI network is unaffected by the failure, log shipping and seeding operations will revert to use the MAPI network. When the failed Replication network is restored, log shipping and seeding operations will revert back to the Replication network. To increase the high availability on your DAG, additional MAPI and/or Replication networks can be added, as needed. Also you can prevent an individual network from being a single point of failure by using network adapter teaming or similar technology.
Can I host other roles on a mailbox server that is member of a DAG?
Unlike Exchange 2007, where clustered mailbox servers required dedicated hardware, Mailbox servers in a DAG can host other Exchange roles (Client Access, Hub Transport, Unified Messaging), providing full redundancy of Exchange services and data with just two servers. This can be an excellent option for small and medium organizations where the number of mailboxes and email traffic doesn't require a dedicated hardware for each role.
A database availability group (DAG) is the base component of the high availability and site resilience framework that is built into Exchange 2010. A DAG is a group of up to 16 Mailbox servers that host a set of databases and provide automatic database-level recovery from failures that affect individual servers or databases. Exchange 2010 uses the same continuous replication technology found in Exchange 2007. Exchange 2010 combines on-site data replication (CCR) and off-site data replication (SCR) into a single framework which is the DAG. Once servers have been added to a DAG, administrators can add replicated database copies incrementally, and Exchange 2010 switches between these copies automatically, as needed, to maintain availability.
When can I create a DAG?
After you've deployed Exchange 2010, you can create a DAG, add Mailbox servers to the DAG, and then replicate mailbox databases between the DAG members. A DAG can be created using the New Database Availability Group wizard in the Exchange Management Console, or by running the New-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. When creating a DAG, you provide a name for the DAG, and optional witness server and witness directory settings. In addition, one or more IP addresses are assigned to the DAG, either by using static IP addresses or by allowing the DAG to be automatically assigned the necessary IP addresses using Dynamic Host Configuration Protocol (DHCP).
Do I need to setup windows cluster for the DAG to work?
No, there is nothing called a standalone or clustered Exchange 2010 installation. After you install a normal Exchange 2010 mailbox server, you need to run the New-DatabaseAvailabilityGroup cmdlet to create a DAG, once the DAG has been created, mailbox servers can be added to the DAG. When the first server is added to the DAG, a cluster is formed for use by the DAG. DAGs make limited use of Windows Failover Clustering technology, namely the cluster heartbeat, cluster networks, and the cluster database (for storing data that changes or can change quickly, such as database state changes from active to passive or vice versa, or from mounted to dismounted and vice versa). As each subsequent server is added to the DAG, it is joined to the underlying cluster (and the cluster's quorum model is automatically adjusted by the system, as needed), and the server is added to the DAG object in Active Directory. And because DAGs rely on Windows Failover Clustering, they can only be created on Exchange 2010 Mailbox servers that are running Windows Server 2008 Enterprise Edition or Windows Server 2008 R2 Enterprise Edition. In addition, each Mailbox server in the DAG must have at least two network interface cards in order to be supported
What's happening when I create a DAG or join a server to an existing DAG?
When the first Mailbox server is added to a DAG, the following occurs:
- The Windows Failover Clustering component is installed, if it is not already installed.
- A failover cluster is created using the name of the DAG.
- A cluster network object (CNO) is created in default computers container.
- The name and IP address of the DAG is registered as a Host (A) record in DNS.
- The server is added to DAG object in Active Directory.
- The cluster database is updated with information on the databases that are mounted on the added server.
When the second and subsequent servers are added to the DAG, the following occurs:
- The server is joined to Windows Failover Cluster for the DAG.
- The quorum model is automatically adjusted:
- A Node Majority quorum model is used for DAGs with an odd number of members.
- A Node and File Share Majority quorum is used for DAGs with an even number of members.
- The witness directory and share are automatically created by Exchange when needed.
- The server is added to DAG object in Active Directory.
- The cluster database is updated with info on mounted databases
Can I have DAG members from different subnets?
Yes, during the cluster creation, the Add-DatabaseAvailabilityGroupServer task retrieves the IP address(es) configured while you are creating the DAG, takes whatever appropriate IP and ignores the ones don't match any of the subnets found on the server. This gives you the flexibility to have a DAG with members on the same or different subnets "in case you will have a DAG node in another datacenter".
Can I use a 3rd party replication tool to replicate the databases in the DAG?
By default, a DAG is designed to use the built-in continuous replication feature to replicate mailbox databases between servers in the DAG. If you are using third-party data replication that supports the Third Party Replication API in Exchange 2010, you must create the DAG in third party replication mode by using the New-DatabaseAvailabilityGroup cmdlet with the ThirdPartyReplication parameter, but note that Once this mode is enabled, it cannot be disabled.
Can I encrypt the DAG network traffic?
DAGs support the use of encryption by leveraging the encryption capabilities of the Windows Server operating system. DAGs use Kerberos authentication between Exchange servers. Microsoft Kerberos SSP’s EncryptMessage/DecryptMessage APIs handle encryption of DAG network traffic. Microsoft Kerberos SSP supports multiple encryption algorithms. The Kerberos authentication handshake picks the strongest encryption protocol supported in the list: typically AES 256-bit, potentially with a SHA Hash Message Authentication Code (HMAC) to maintain integrity of the data
Can I compress the DAG network communication?
DAGs also support built-in compression. When compression is enabled, DAG network communication uses XPRESS, which is Microsoft’s implementation of the LZ77 algorithm. This is the same type of compression used in many Microsoft protocols, in particular, MAPI RPC compression between Outlook and Exchange
What is the minimum network interfaces required for a DAG?
As indicated above, each Mailbox server in the DAG must have at least two network interface cards in order to be supported. In Exchange 2010, DAGs primarily have two types of networks: MAPI networks, which are used by other Exchange 2010 servers to communicate with the Mailbox server in the DAG, and Replication networks, which are used for log shipping and seeding within the DAG. So the reason to have at least two NICs is that this configuration enables you to configure one MAPI network and one Replication network.
What will happen if one of my DAG networks encountered a failure?
In the event of a failure affecting the MAPI network, a server failover will occur (assuming there are healthy mailbox database copies that can be activated). In the event of a failure affecting the Replication network, if the MAPI network is unaffected by the failure, log shipping and seeding operations will revert to use the MAPI network. When the failed Replication network is restored, log shipping and seeding operations will revert back to the Replication network. To increase the high availability on your DAG, additional MAPI and/or Replication networks can be added, as needed. Also you can prevent an individual network from being a single point of failure by using network adapter teaming or similar technology.
Can I host other roles on a mailbox server that is member of a DAG?
Unlike Exchange 2007, where clustered mailbox servers required dedicated hardware, Mailbox servers in a DAG can host other Exchange roles (Client Access, Hub Transport, Unified Messaging), providing full redundancy of Exchange services and data with just two servers. This can be an excellent option for small and medium organizations where the number of mailboxes and email traffic doesn't require a dedicated hardware for each role.
Wednesday, December 2, 2009
Difference between Unified Messaging and Unified Communications
UM is a part of UC. In other words, UC includes UM, but UC also includes a lot of other important products and technologies. A customer who uses Microsoft's Office, SharePoint, Exchange and Office Communications Server products has an opportunity to experience many more UC scenarios than a customer using Exchange (and UM) only. Office Communications Servers' support for enterprise class presence, instant messaging and voice, combined with the ability of Office, SharePoint and Exchange to use this support, creates many useful and interesting new possibilities for the end user.
A simple example of the power and convenience of UC can be seen when a user receives a voice message (created by Exchange UM) from another user and opens it in Outlook. Not only can they listen to the message, but they can see the other user's presence status, and start an instant messaging or voice conversation with them. Not only are there more ways for users to communicate with each other, but they are woven together into an intuitive, unified experience by the software.
UC offers so many possible combinations and sequences of interactive communication that it is easy to be dazzled by the details and lose sight of the underlying principles. The user is placed at the center: they are able to communicate with others from the most convenient device, with the most appropriate method, at the right time. Unified Messaging (UM) participates in some of these scenarios (indeed, it is an integral part of many of them), but is just a component of the larger UC picture.
In the "old world", customers had a PBX and voice mail. Now, they can have a Unified Communications system, where Office Communications Server plays the part of the PBX (and much more), and Exchange Unified Messaging replaces legacy voice mail. In this "new world", many new possibilities have opened up, but some familiar patterns and interactions still occur.
A simple example of the power and convenience of UC can be seen when a user receives a voice message (created by Exchange UM) from another user and opens it in Outlook. Not only can they listen to the message, but they can see the other user's presence status, and start an instant messaging or voice conversation with them. Not only are there more ways for users to communicate with each other, but they are woven together into an intuitive, unified experience by the software.
UC offers so many possible combinations and sequences of interactive communication that it is easy to be dazzled by the details and lose sight of the underlying principles. The user is placed at the center: they are able to communicate with others from the most convenient device, with the most appropriate method, at the right time. Unified Messaging (UM) participates in some of these scenarios (indeed, it is an integral part of many of them), but is just a component of the larger UC picture.
In the "old world", customers had a PBX and voice mail. Now, they can have a Unified Communications system, where Office Communications Server plays the part of the PBX (and much more), and Exchange Unified Messaging replaces legacy voice mail. In this "new world", many new possibilities have opened up, but some familiar patterns and interactions still occur.
Subscribe to:
Posts (Atom)