Jump to content

i-away

Members
 View Profile  See their activity

  • Posts

    462

  • Joined

  • Last visited

 Content Type 

Blog Entries posted by i-away

  1. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues.

    Known issues in this cumulative update
    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions.
    Notes:If you are upgrading from Cumulative Update 2 for Exchange Server 2019 to Cumulative Update 3 for Exchange Server 2019, then there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you has ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of.

    a. About the /PrepareDomain operation in multidomain:

    The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest.

    b. About the permission question:

    As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages:


    To avoid the error messages, either the user should join Schema Admins and Enterprise Admins groups, or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then the Exchange admin user can start Setup. The Set-SendConnector cmdlet does not work for Exchange Server 2019 in hybrid scenarios that have a Edge server installed. For more information, see KB 4523519.  Autodiscover Event ID 1 after installing Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. Issues that this cumulative update fixes
    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:
    4515257 Hash mismatch is reported for Exchange DLLs in the bin directory of Exchange Server 2019 4513500 Can’t sign in to OWA or EAC after you install Exchange Server 2019 CU2 with AD FS 4502159 Adding or removing mailbox permission in EAC doesn’t address the msExchDelegateListLink attribute in Exchange Server 2019 and 2016 4515276 Room mailbox accepts a meeting as “Free” if a booking delegate is set in Exchange Server 2019 and 2016 4515275 Enable Get/Restore-RecoverableItems to work with Purges folder in Exchange Server 2019 and 2016 4515274 AutodiscoverV2 request returns REST API endpoint not AutoDiscoverV1 endpoint in Exchange Server 2019 and 2016 4515269 SentToMemberOf shows every recipient type not distribution groups when you create transport rule in Exchange Server 2019 and 2016 4515272 Message is blocked in “SMTP Delivery to Mailbox” queue if exchange server is added in groups of a child domain in Exchange Server 2019 and 2016 4515271 Can’t convert a migrated remote user mailbox to shared in Exchange Server 2019 and 2016 4515270 SubmissionQueueLengthMonitor shows “System.ArgumentException: Transition timeout…” in Exchange Server 2019 and 2016 4515267 NDR occurs when you resend message from alternate journaling mailbox to journaling mailbox in Exchange Server 2019 and 2016 4515265 Removing In-Place Hold doesn’t work for mailboxes in different domains in Exchange Server 2019 and 2016 4515264 FindPeople request from Skype for Business on Mac fails with “Invalid Shape Specification” in Exchange Server 2019 and 2016 4515263 Hide the “Validate-MailFlowThroughFrontDoor” command for Exchange Server 2019 and 2016 4515262 Enable Remove-MobileDevice to delete mobile devices after migrating to Office 365 from Exchange Server 2019 and 2016 4515261 Can’t copy eDiscovery search results for mailboxes with Exchange online archives in Office 365 in Exchange Server 2019 and 2016 4515273 Mailbox auditing fails when using SHA1Managed in Exchange Server 2019 and 2016 4515266 Infinite loop in Recurrence.GetNumberOfYearsBetween() with the Japanese calendar in Exchange Server 2019 and 2016 4520319 S/MIME signed reply draft behaves like the first message in conversation in Exchange Server 2019 and 2016 4515832 Description of the security update for Microsoft Exchange Server 2019 and 2016: September 10, 2019
  2. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues.
    Known issues in this cumulative update
    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions.
    Notes:If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 4 for Exchange Server 2019, then there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you has ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of.

    a. About the /PrepareDomain operation in multidomain:

    The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest.

    b. About the permission question:

    As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages:


    To avoid the error messages, either the user should join Schema Admins and Enterprise Admins groups, or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then the Exchange admin user can start Setup. Autodiscover Event ID 1 after installing Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. The Export-ModernPublicFolderStatistics.ps1 script doesn’t work in Microsoft Exchange Server 2019. For more information, see KB 4536552. Issues that this cumulative update fixes
    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:
    4528696 Exchange PowerShell cmdlets take longer time to run in Exchange Server 2019 4528695 Event ID 4009 when using SubjectOrBodyMatchesPatterns on Edge server in Exchange Server 2019 4528694 Can’t open .ics file in Outlook on the web in Exchange Server 2019 4528692 “A parameter was specified that isn’t valid” error when creating transport rule in Exchange Server 2019 4523519 Set-SendConnector doesn’t work for Exchange Server in hybrid scenarios with Edge Server installed 4528688 Only one recipient shows when saving draft by using Exchange ActiveSync version 16.0 in Exchange Server 2019 4528693 Get-CalendarDiagnosticLog is proxied for queries within the same forest in Exchange Server 2019 4528687 NotificationClient logs aren’t purged and consume lots of disk in Exchange Server 2019 4528689 Outlook on the web shows MailTip when recipients equal the large audience size in Exchange Server 2019 4528690 Can’t move or delete folder in Outlook online mode if the destination has a folder with the same name in Exchange Server 2019 4532744 System.ArgumentNullException when you use Set-user to assign block legacy auth policy in Exchange Server 2019 4532747 Address list separation not working for a user without a mailbox in Exchange Server 2019 4523171 Description of the security update for Microsoft Exchange Server 2019, 2016, and 2013: November 12, 2019

  3. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues.
    Known issues in this cumulative update
    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions.
    Notes:If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 4 for Exchange Server 2019, then there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you has ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of.

    a. About the /PrepareDomain operation in multidomain:

    The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest.

    b. About the permission question:

    As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages:


    To avoid the error messages, either the user should join Schema Admins and Enterprise Admins groups, or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then the Exchange admin user can start Setup. Autodiscover Event ID 1 after installing Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. The Export-ModernPublicFolderStatistics.ps1 script doesn’t work in Microsoft Exchange Server 2019. For more information, see KB 4536552. Issues that this cumulative update fixes
    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:
    4528696 Exchange PowerShell cmdlets take longer time to run in Exchange Server 2019 4528695 Event ID 4009 when using SubjectOrBodyMatchesPatterns on Edge server in Exchange Server 2019 4528694 Can’t open .ics file in Outlook on the web in Exchange Server 2019 4528692 “A parameter was specified that isn’t valid” error when creating transport rule in Exchange Server 2019 4523519 Set-SendConnector doesn’t work for Exchange Server in hybrid scenarios with Edge Server installed 4528688 Only one recipient shows when saving draft by using Exchange ActiveSync version 16.0 in Exchange Server 2019 4528693 Get-CalendarDiagnosticLog is proxied for queries within the same forest in Exchange Server 2019 4528687 NotificationClient logs aren’t purged and consume lots of disk in Exchange Server 2019 4528689 Outlook on the web shows MailTip when recipients equal the large audience size in Exchange Server 2019 4528690 Can’t move or delete folder in Outlook online mode if the destination has a folder with the same name in Exchange Server 2019 4532744 System.ArgumentNullException when you use Set-user to assign block legacy auth policy in Exchange Server 2019 4532747 Address list separation not working for a user without a mailbox in Exchange Server 2019 4523171 Description of the security update for Microsoft Exchange Server 2019, 2016, and 2013: November 12, 2019
  4. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues.
    Known issues in this cumulative update
    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions.
    Notes:If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 4 for Exchange Server 2019, then there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you has ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of.

    a. About the /PrepareDomain operation in multidomain:

    The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest.

    b. About the permission question:

    As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages:


    To avoid the error messages, either the user should join Schema Admins and Enterprise Admins groups, or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then the Exchange admin user can start Setup. Autodiscover Event ID 1 after installing Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. The Export-ModernPublicFolderStatistics.ps1 script doesn’t work in Microsoft Exchange Server 2019. For more information, see KB 4536552. Issues that this cumulative update fixes
    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:
    4528696 Exchange PowerShell cmdlets take longer time to run in Exchange Server 2019 4528695 Event ID 4009 when using SubjectOrBodyMatchesPatterns on Edge server in Exchange Server 2019 4528694 Can’t open .ics file in Outlook on the web in Exchange Server 2019 4528692 “A parameter was specified that isn’t valid” error when creating transport rule in Exchange Server 2019 4523519 Set-SendConnector doesn’t work for Exchange Server in hybrid scenarios with Edge Server installed 4528688 Only one recipient shows when saving draft by using Exchange ActiveSync version 16.0 in Exchange Server 2019 4528693 Get-CalendarDiagnosticLog is proxied for queries within the same forest in Exchange Server 2019 4528687 NotificationClient logs aren’t purged and consume lots of disk in Exchange Server 2019 4528689 Outlook on the web shows MailTip when recipients equal the large audience size in Exchange Server 2019 4528690 Can’t move or delete folder in Outlook online mode if the destination has a folder with the same name in Exchange Server 2019 4532744 System.ArgumentNullException when you use Set-user to assign block legacy auth policy in Exchange Server 2019 4532747 Address list separation not working for a user without a mailbox in Exchange Server 2019 4523171 Description of the security update for Microsoft Exchange Server 2019, 2016, and 2013: November 12, 2019
  5. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues
    Κnown issues in this cumulative update
    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions.

    NotesIf you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 5 for Exchange Server 2019, there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain:

    The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest. About the permission question:

    As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages.



    To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then, the Exchange admin user can start Setup. Autodiscover Event ID 1 occurs after you install Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. Issues that this cumulative update fixes
    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:
    4552472 Exchange Server 2019 Sizing Calculator version 10.4 is available 4536552 Export-ModernPublicFolderStatistics.ps1 is not working in Exchange Server 2019 4538303 Exchange 2019 Setup Prerequisite Check fails for .NET 4.8 Framework in CU4 on Windows builds 1909 and 1903 4547705 Authentication loop between msft.sts.microsoft.com/adfs and OWA in Exchange Server 2019 4547706 Birthday isn’t correctly synced to iOS native mail app in Exchange Server 2019 4547708 Elevation of privileges possible when Active Directory permissions role is granted in Exchange Server 2019 4547709 InternetWebProxyBypassList is ignored by Mailbox Replication service in Exchange Server 2019 4547710 New-MailboxSearch with In-Place Hold enabled replaces all values in msExchUserHoldPolicies if adding a value in Exchange Server 2019 4547711 Public folder permissions aren’t applied from Outlook in Exchange Server 2019 hybrid environment 4547712 Outlook on the web (OWA) exposes junk operations even if disabled via OwaMailboxPolicy in Exchange Server 2019 4547713 IsOnlineMeeting is always false for Teams-only meetings in Exchange Server 2019 4547714 Can’t add remote shared mailbox using ECP into distribution group in Exchange Server 2019 hybrid environment 4547715 New created search folder retention policy is changed in Exchange Server 2019 4547719 MCDB status is “Offline” and SSDs are not formatted in Exchange Server 2019 4547720 Partial word searches not working for mailboxes in Outlook online mode in Exchange Server 2019 4547721 Exchange Sizing Calculator still supports mail.que database over 2 TB in Exchange Server 2019 4547722 Can’t go from Office 365 to Enterprise in Exchange Server 2019 Exchange admin center (EAC) if Chrome SameSite Cookie is enabled 4547723 Can’t sign in to Office 365 if configuring hybrid with Chrome SameSite Cookie enabled in Exchange Server 2019 4536987 Description of the security update for Microsoft Exchange Server 2019: February 11, 2020 4540123 Description of the security update for Microsoft Exchange Server 2019: March 10, 2020


  6. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues


    Κnown issues in this cumulative update





    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes
    If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 5 for Exchange Server 2019, there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest.
    About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages.

    To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then, the Exchange admin user can start Setup.
    Autodiscover Event ID 1 occurs after you install Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190.

    Issues that this cumulative update fixes





    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:


    4552472 Exchange Server 2019 Sizing Calculator version 10.4 is available 4536552 Export-ModernPublicFolderStatistics.ps1 is not working in Exchange Server 2019 4538303 Exchange 2019 Setup Prerequisite Check fails for .NET 4.8 Framework in CU4 on Windows builds 1909 and 1903 4547705 Authentication loop between msft.sts.microsoft.com/adfs and OWA in Exchange Server 2019 4547706 Birthday isn’t correctly synced to iOS native mail app in Exchange Server 2019 4547708 Elevation of privileges possible when Active Directory permissions role is granted in Exchange Server 2019 4547709 InternetWebProxyBypassList is ignored by Mailbox Replication service in Exchange Server 2019 4547710 New-MailboxSearch with In-Place Hold enabled replaces all values in msExchUserHoldPolicies if adding a value in Exchange Server 2019 4547711 Public folder permissions aren’t applied from Outlook in Exchange Server 2019 hybrid environment 4547712 Outlook on the web (OWA) exposes junk operations even if disabled via OwaMailboxPolicy in Exchange Server 2019 4547713 IsOnlineMeeting is always false for Teams-only meetings in Exchange Server 2019 4547714 Can’t add remote shared mailbox using ECP into distribution group in Exchange Server 2019 hybrid environment 4547715 New created search folder retention policy is changed in Exchange Server 2019 4547719 MCDB status is “Offline” and SSDs are not formatted in Exchange Server 2019 4547720 Partial word searches not working for mailboxes in Outlook online mode in Exchange Server 2019 4547721 Exchange Sizing Calculator still supports mail.que database over 2 TB in Exchange Server 2019 4547722 Can’t go from Office 365 to Enterprise in Exchange Server 2019 Exchange admin center (EAC) if Chrome SameSite Cookie is enabled 4547723 Can’t sign in to Office 365 if configuring hybrid with Chrome SameSite Cookie enabled in Exchange Server 2019 4536987 Description of the security update for Microsoft Exchange Server 2019: February 11, 2020 4540123 Description of the security update for Microsoft Exchange Server 2019: March 10, 2020


  7. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues


    Κnown issues in this cumulative update





    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes
    If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 5 for Exchange Server 2019, there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest.
    About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages.

    To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then, the Exchange admin user can start Setup.
    Autodiscover Event ID 1 occurs after you install Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190.

    Issues that this cumulative update fixes





    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:


    4552472 Exchange Server 2019 Sizing Calculator version 10.4 is available 4536552 Export-ModernPublicFolderStatistics.ps1 is not working in Exchange Server 2019 4538303 Exchange 2019 Setup Prerequisite Check fails for .NET 4.8 Framework in CU4 on Windows builds 1909 and 1903 4547705 Authentication loop between msft.sts.microsoft.com/adfs and OWA in Exchange Server 2019 4547706 Birthday isn’t correctly synced to iOS native mail app in Exchange Server 2019 4547708 Elevation of privileges possible when Active Directory permissions role is granted in Exchange Server 2019 4547709 InternetWebProxyBypassList is ignored by Mailbox Replication service in Exchange Server 2019 4547710 New-MailboxSearch with In-Place Hold enabled replaces all values in msExchUserHoldPolicies if adding a value in Exchange Server 2019 4547711 Public folder permissions aren’t applied from Outlook in Exchange Server 2019 hybrid environment 4547712 Outlook on the web (OWA) exposes junk operations even if disabled via OwaMailboxPolicy in Exchange Server 2019 4547713 IsOnlineMeeting is always false for Teams-only meetings in Exchange Server 2019 4547714 Can’t add remote shared mailbox using ECP into distribution group in Exchange Server 2019 hybrid environment 4547715 New created search folder retention policy is changed in Exchange Server 2019 4547719 MCDB status is “Offline” and SSDs are not formatted in Exchange Server 2019 4547720 Partial word searches not working for mailboxes in Outlook online mode in Exchange Server 2019 4547721 Exchange Sizing Calculator still supports mail.que database over 2 TB in Exchange Server 2019 4547722 Can’t go from Office 365 to Enterprise in Exchange Server 2019 Exchange admin center (EAC) if Chrome SameSite Cookie is enabled 4547723 Can’t sign in to Office 365 if configuring hybrid with Chrome SameSite Cookie enabled in Exchange Server 2019 4536987 Description of the security update for Microsoft Exchange Server 2019: February 11, 2020 4540123 Description of the security update for Microsoft Exchange Server 2019: March 10, 2020


  8. i-away
    Μόλις έγινε διαθέσιμο το Exchange Server 2013 Cumulative Update 5. Περιλαμβάνει αρκετές διορθώσεις και βελτιώσεις σε κάποια προσφάτως παρατηρημένα προβλήματα.
    Μπορείτε να το κατεβάσετε απο εδώ
    Ενδεικτικά κάποιες βελτιώσεις – διορθώσεις:

    2991934 Duplicate mailbox folders after migration to Exchange Server 2013

    2988229 Hybrid Configuration wizard error “Subtask CheckPrereqs execution failed” for Exchange Server 2013

    2986779 EMS takes a long time to execute the first command in an Exchange Server 2013 Cumulative Update 5 environment

    2983512 RPC Client Access service crashes on an on-premises Mailbox server in an Exchange Server 2013 hybrid environment

    2983426 AutodiscoverSelfTestProbe fails when external URL is not set for EWS virtual directory in Exchange Server 2013

    2983423 AutodiscoverSelfTestProbe fails when external URL is not set for ECP virtual directory in Exchange Server 2013

    2983422 The ServerWideOffline component is set to Inactive after Exchange Server 2013 prerequisite check fails

    2983207 “532 5.3.2″ NDR when you send an email message to a hidden mailbox in an Exchange Server 2013 environment

    2983066 Removed Default or Anonymous permission for Outlook folders cannot be restored in an Exchange Server 2013 environment

    2982769 “Topology service cannot find the OWA service” when you perform an eDiscovery search in Exchange Server 2013

    2982763 Mail-enabled public folder accepts email messages from unauthorized users in an Exchange Server 2013 environment

    2982762 OAB generation arbitration mailbox can be removed or disabled in an Exchange Server 2013 environment

    2982760 The Enter key submits duplicate sign-in forms to Outlook Web App in an Exchange Server 2013 environment

    2982759 You cannot access the archive mailbox of a delegated user after enabling MAPI over HTTP

    2982017 Incorrect voice mail message duration in an Exchange Server 2013 environment

    2981835 You cannot add attachments, delete or move many email messages in bulk in Outlook Web App

    2981466 MAPI/CDO client cannot connect to Exchange Server 2013

    2977279 You cannot disable journaling for protected voice mail in an Exchange Server 2013 environment

    2975599 Exchange Server 2010 public folder replication fails in an Exchange Server 2013 environment

    2975003 Calendar item body disappears in Outlook online mode in an Exchange Server 2013 environment

    2974339 OAB generation fails if FIPS is used in an Exchange Server 2013 environment

    2971270 Blank page after you sign in to Exchange Server 2013 EAC (formerly ECP)

    2970040 Folder Assistant rule does not work correctly in an Exchange Server 2013 environment

    2965689 EAS device cannot sync free/busy status if an item is created by EWS in an Exchange Server 2013 environment

    2963590 Message routing latency if IPv6 is enabled in Exchange Server 2013

    2961715 “Something went wrong” error in Outlook Web App may show an incorrect date

    2958434 Users cannot access mailboxes in OWA or EAS when mailbox database is removed

    2993556 Sender’s DKIM signature is broken in an Exchange Server 2013 environment

    This update also includes new daylight saving time (DST) updates for Exchange Server 2013. For more information about DST, go to the following Microsoft website:
    Daylight Saving Time Help and Support Center
    Filed under: Exchange, Exchange 2013, News
     
    Source
  9. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues

    Cumulative Update 6 for Microsoft Exchange Server 2019 was released on June 16, 2020. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. These fixes will also be included in later cumulative updates for Exchange Server 2019. 
    This update also includes new daylight saving time (DST) updates for Exchange Server 2019. For more information about DST, see Daylight Saving Time Help and Support Center.
    Known issues in this cumulative update
    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions.

    NotesIf you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 6 for Exchange Server 2019, there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain:

    The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest. About the permission question:

    As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages.



    To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then, the Exchange admin user can start Setup. Autodiscover Event ID 1 occurs after you install Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190. Issues that this cumulative update fixes
    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:
    4559441 Foreign language characters set in RejectMessageReasonText of a transport rule aren’t shown correctly in Exchange Server 2019 4547707 Enable piping for Restore-RecoverableItems in Exchange Server 2019 4549689 HMA EvoSTS certificate rollover causes authentication prompts due to stalled key on worker process spawn (warmup phase) in Exchange Server 2019 4559446 Changes to Outlook on the web blocked file extensions and MIME types in Exchange Server 2019 4559440 Export to a PST for an eDiscovery search fails Exchange Server 2019 4559439 EAS creates failure report if a message with unknown recipients is in Drafts in Exchange Server 2019 4559442 2080 Events caused by empty values in HKLM\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess\Instance0 in Exchange Server 2019 4559438 Edge Transport server hangs in Exchange Server 2019 4559443 Managed Folder Assistant fails with Event ID 9004 NotInBagPropertyErrorException in Exchange Server 2019 4559437 PR_RECIPIENT_ENTRYID is computed if no email address or type in Exchange Server 2019 4559444 Conversion from HTML to RTF removes non-breaking space in Exchange Server 2019 4559436 Attachments with properties (like Azure Information Protection labels) not always matching in Exchange Server 2019 4559435 Introduce an OrganizationConfig flag to enable or disable recipient read session in Exchange Server 2019

  10. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues




    Cumulative Update 6 for Microsoft Exchange Server 2019 was released on June 16, 2020. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. These fixes will also be included in later cumulative updates for Exchange Server 2019.


    This update also includes new daylight saving time (DST) updates for Exchange Server 2019. For more information about DST, see Daylight Saving Time Help and Support Center.


    Known issues in this cumulative update





    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes
    If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 6 for Exchange Server 2019, there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest.
    About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages.

    To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then, the Exchange admin user can start Setup.
    Autodiscover Event ID 1 occurs after you install Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190.

    Issues that this cumulative update fixes





    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:


    4559441 Foreign language characters set in RejectMessageReasonText of a transport rule aren’t shown correctly in Exchange Server 2019 4547707 Enable piping for Restore-RecoverableItems in Exchange Server 2019 4549689 HMA EvoSTS certificate rollover causes authentication prompts due to stalled key on worker process spawn (warmup phase) in Exchange Server 2019 4559446 Changes to Outlook on the web blocked file extensions and MIME types in Exchange Server 2019 4559440 Export to a PST for an eDiscovery search fails Exchange Server 2019 4559439 EAS creates failure report if a message with unknown recipients is in Drafts in Exchange Server 2019 4559442 2080 Events caused by empty values in HKLM\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess\Instance0 in Exchange Server 2019 4559438 Edge Transport server hangs in Exchange Server 2019 4559443 Managed Folder Assistant fails with Event ID 9004 NotInBagPropertyErrorException in Exchange Server 2019 4559437 PR_RECIPIENT_ENTRYID is computed if no email address or type in Exchange Server 2019 4559444 Conversion from HTML to RTF removes non-breaking space in Exchange Server 2019 4559436 Attachments with properties (like Azure Information Protection labels) not always matching in Exchange Server 2019 4559435 Introduce an OrganizationConfig flag to enable or disable recipient read session in Exchange Server 2019
  11. i-away
    This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues




    Cumulative Update 6 for Microsoft Exchange Server 2019 was released on June 16, 2020. This cumulative update is a security update. It includes fixes for nonsecurity issues and all previously released fixes for security and nonsecurity issues. These fixes will also be included in later cumulative updates for Exchange Server 2019.


    This update also includes new daylight saving time (DST) updates for Exchange Server 2019. For more information about DST, see Daylight Saving Time Help and Support Center.


    Known issues in this cumulative update





    In multidomain Active Directory forests in which Exchange is installed or has been prepared previously by using the /PrepareDomain option in Setup, this action must be completed after the /PrepareAD command for this cumulative update has been completed and the changes are replicated to all domains. Setup will try to run the /PrepareAD command during the first server installation. Installation will finish only if the user who initiated Setup has the appropriate permissions. Notes
    If you are upgrading from Cumulative Update 2 for Exchange Server 2019 or a later cumulative update for Exchange Server 2019 to Cumulative Update 6 for Exchange Server 2019, there’s no need to run the /PrepareAD or /PrepareDomain. No additional actions (prepareAD, prepareDomain, or assigning permissions) are required. If you have ever skipped a Cumulative Update (for example, you are upgrading from an earlier version before Cumulative Update 2 for Exchange Server 2019), or this is a first Exchange Server installation in the AD, then this Known Issue section should be taken care of. About the /PrepareDomain operation in multidomain: The /PrepareDomain operation automatically runs in the Active Directory domain in which the /PrepareAD commandis run. However, it may be unable to update other domains in the forest. Therefore, a domain administrator should run the /PrepareDomain in other domains in the forest.
    About the permission question: As the /PrepareAD is triggered in Setup, if the user who initiates Setup isn’t a member of Schema Admins and Enterprise Admins, the readiness check will fail and you receive the following error messages.

    To avoid the errors, either the user should join Schema Admins and Enterprise Admins groups or another user in Schema Admins and Enterprise Admins groups manually runs the /PrepareAD for this Cumulative Update first. Then, the Exchange admin user can start Setup.
    Autodiscover Event ID 1 occurs after you install Cumulative Update 3 for Exchange Server 2019. For more information, see KB 4532190.

    Issues that this cumulative update fixes





    This cumulative update also fixes the issues that are described in the following Microsoft Knowledge Base articles:


    4559441 Foreign language characters set in RejectMessageReasonText of a transport rule aren’t shown correctly in Exchange Server 2019 4547707 Enable piping for Restore-RecoverableItems in Exchange Server 2019 4549689 HMA EvoSTS certificate rollover causes authentication prompts due to stalled key on worker process spawn (warmup phase) in Exchange Server 2019 4559446 Changes to Outlook on the web blocked file extensions and MIME types in Exchange Server 2019 4559440 Export to a PST for an eDiscovery search fails Exchange Server 2019 4559439 EAS creates failure report if a message with unknown recipients is in Drafts in Exchange Server 2019 4559442 2080 Events caused by empty values in HKLM\SYSTEM\CurrentControlSet\Services\MSExchange ADAccess\Instance0 in Exchange Server 2019 4559438 Edge Transport server hangs in Exchange Server 2019 4559443 Managed Folder Assistant fails with Event ID 9004 NotInBagPropertyErrorException in Exchange Server 2019 4559437 PR_RECIPIENT_ENTRYID is computed if no email address or type in Exchange Server 2019 4559444 Conversion from HTML to RTF removes non-breaking space in Exchange Server 2019 4559436 Attachments with properties (like Azure Information Protection labels) not always matching in Exchange Server 2019 4559435 Introduce an OrganizationConfig flag to enable or disable recipient read session in Exchange Server 2019
  12. i-away
    It’s been a few months since we announced some major changes to our virtualization support statements for Exchange 2010 (see Announcing Enhanced Hardware Virtualization Support for Exchange 2010).
    Over that time, I’ve received quite a few excellent questions about
    particular deployment scenarios and how the changes to our support
    statements might affect those deployments. Given the volume of
    questions, it seemed like an excellent time to post some additional
    information and clarification.
    First of all, a bit of
    background. When we made the changes to our support statements, the
    primary thing we wanted to ensure was that our customers wouldn’t get
    into a state where Exchange service availability might be reduced as a
    result of using a virtualized deployment. To put it another way, we
    wanted to make sure that the high level of availability that can be
    achieved with a physical deployment of the Exchange 2010 product would
    not in any way be reduced by deploying on a virtualization platform. Of
    course, we also wanted to ensure that the product remained functional
    and that we verified that the additional functionality provided by the
    virtualization stack would not provide an opportunity for loss of any
    Exchange data during normal operation.
    Given these points, here’s a quick overview of what we changed and what it really means.
    Let’s go over some definitions to make sure we are all thinking about the terms in those support statements in the same way.
    Cold boot
    This refers to the action of bringing up a system from a power-off
    state into a clean start of the operating system. No operating system
    state has been persisted in this case. Saved state
    When a virtual machine is powered off, hypervisors typically have the
    ability to save the state of the virtual machine at that point in time
    so that when the machine is powered back on it will return to that state
    rather than going through a “cold boot” startup. “Saved state” would be
    the result of a “Save” operation in Hyper-V. Planned migration
    When a system administrator initiates the move of a virtual machine
    from one hypervisor host to another we call this a planned migration.
    This could be a single migration, or a system admin could configure some
    automation that is responsible for moving the virtual machine on a
    timed basis or as a result of some other event that occurs in the system
    other than hardware or software failure. The key point here is that the
    Exchange virtual machine is operating normally and needs to be
    relocated for some reason – this can be done via a technology like Live
    Migration or vMotion. If the Exchange virtual machine or the hypervisor
    host where the VM is located experiences some sort of failure condition,
    then the result of that would not be “planned”. Virtualizing Unified Messaging Servers
    One
    of the changes made was the addition of support for the Unified
    Messaging role on Hyper-V and other supported hypervisors. As I
    mentioned at the beginning of this article, we did want to ensure that
    any changes we made to our support statement resulted in the product
    remaining fully functional and providing the best possible service to
    our users. As such, we require Exchange Server 2010 SP1 to be deployed
    for UM support. The reason
    for this is quite straightforward. The UM role is dependent on a media
    component provided by the Microsoft Lync team. Our partners in Lync did
    some work prior to the release of Exchange 2010 SP1 to enable high
    quality real-time audio processing in a virtual deployment, and in the
    SP1 release of Exchange 2010 we integrated those changes into the UM
    role. Once that was accomplished, we did some additional testing to
    ensure that user experience would be as optimal as possible and modified
    our support statement.
    As you’ll notice, we do have specific
    requirements around CPU configuration for virtual machines (and
    hypervisor host machines) where UM is being run. This is additional
    insurance against poor user experience (which would show up as poor
    voice quality).
    Host-based Failover Clustering & Migration
    Much
    of the confusion around the changed support statement stems from the
    details on combination of host-based failover clustering & migration
    technology with Exchange 2010 DAGs). The guidance here is really quite simple.
    First, let’s talk about whether we support third-party migration technology
    (like VMware’s vMotion). Microsoft can’t make “support” statements for
    the integration of 3rd-party hypervisor products using these
    technologies with Exchange 2010, as these technologies are not part of
    the Server Virtualization Validation Program
    (SVVP) which covers the other aspects of our support for 3rd-party
    hypervisors. We make a generic statement here about support, but in
    addition you need to ensure that your hypervisor vendor supports the
    combination of their migration/clustering technology with Exchange 2010.
    To put it as simply as possible: if your hypervisor vendor supports
    their migration technology with Exchange 2010, then we support Exchange
    2010 with their migration technology.
    Second, let’s talk about how we define host-based failover clustering. This refers to any
    sort of technology that provides automatic ability to react to
    host-level failures and start affected VMs on alternate servers.
    Use of this technology is absolutely supported within the provided
    support statement given that in a failure scenario, the VM will be
    coming up from a cold boot on the alternate host. We want to ensure that
    the VM will never come up from saved state that is persisted on disk,
    as it will be “stale” relative to the rest of the DAG members.
    Third, when it comes to migration technology in the support statement, we are talking about any sort of technology that allows a planned move of a VM from one host machine to another.
    Additionally, this could be an automated move that occurs as part of
    resource load balancing (but is not related to a failure in the system).
    Migrations are absolutely supported as long as the VMs never come up
    from saved state that is persisted on disk. This means that technology
    that moves a VM by transporting the state and VM memory over the network
    with no perceived downtime are supported for use with Exchange 2010.
    Note that a 3rd-party hypervisor vendor must provide support for the
    migration technology, while Microsoft will provide support for Exchange
    when used in this configuration. In the case of Microsoft Hyper-V, this
    would mean that Live Migration is supported, but Quick Migration is not.

    With Hyper-V, it’s important to be aware that the default behavior when selecting the “Move” operation on a VM is actually to perform a Quick Migration. To stay in a supported state with Exchange 2010 SP1 DAG
    members, it’s critical that you adjust this behavior as shown in the VM
    settings below (the settings displayed here represent how you should
    deploy with Hyper-V):

    Figure 1: The correct Hyper-V virtual machine behavior for Database Availability Group members Let’s
    review. In Hyper-V, Live Migration is supported for DAG members, but
    Quick Migration is not. Visually, this means that this is supported:

    Figure 2: Live Migration of Database Availability Group member in Hyper-V is supported (see large screenshot) And this is not supported:

    Figure 3: Quick Migration of Database Availability Group members is not supported Hopefully
    this helps to clarify our support statement and guidance for the SP1
    changes. We look forward to any feedback you might have!


    Source





  13. i-away
    “Είστε IT administrator σε μια μεγάλη εταιρεία… Εφαρμόζετε αλλεπάλληλα group policy , κάνετε νέα mailbox , users ,ous…. . Κάπου εκεί ο δαίμονας του πληκτρολογίου χτυπά και εξαφανίζει το αποτέλεσμα της πολύωρης εργασίας σας αφήνοντας σας στα πρόθυρα εγκεφαλικού “
    Το παραπάνω περιγράφει γλαφυρά  μια κατάσταση στην οποία έχουμε βρεθεί λίγο πολύ όλοι μας. Η διαδικασία η οποία θα ακολουθούσαμε σε τέτοια περίπτωση μέχρι πρόσφατα ήταν αρκετά επίπονη και χρονοβόρα . Ποιός δεν έχει περάσει αρκετές ώρες κάνοντας Active Directory Restore ….
    Ευτυχώς η Microsoft στην καινούργια έκδοση των Windows Server 2008 R2 ήρθε μα διευκολύνει την ζωή και να εξασφαλίσει την ψυχική ηρεμία των απανταχού  administrators εισάγοντας μια μικρή αλλά καθόλου ασήμαντη βελτίωση που ακούει στο όνομα  Active directory snapshots . Περισσότερα για αυτή την λειτουργία θα βρείτε στο webcast  του κυρίου Σπανουγάκη εδώ. Αυτό που θα δούμε εδώ είναι ένα χρήσιμο εργαλείο που εκμεταλλεύεται αυτή την λειτουργία και μας λύνει τα χέρια όταν χρειάζεται να διορθώσουμε “μικρά “ λαθάκια στο Active Directory.
    Το πολύ χρήσιμο αυτό εργαλείο ακούει στο όνομα DSCT η αλλιώς Directory Services Comparison Tool  και είναι διαθέσιμο για 64-bit εδώ και για 32-bit εδώ .
     
    Η χρήση του είναι απλή και εύκολη  και προϋποθέτει μόνο την δημιουργία ενός snapshot πριν από κάθε αλλαγή στο Active Directory . Για την διαδικασία αυτή θα σας παραπέμψω στο παραπάνω webcast του κ. Σπανουγάκη . Εδώ να υπογραμμίσω οτι τα snapshots ΔΕΝ υποκαθιστούν σε καμία περίπτωση το κανονικό backup που ΠΡΕΠΕΙ  να γίνεται σε καθημερινή βάση.

    Αφού λοιπόν δημιουργήσουμε με επιτυχία το snapshot , εγκαθιστούμε το DSCT. Αυτό που θα παρατηρήσουμε αμέσως είναι ότι δεν μας εμφανίζει κάποια συντόμευση ή κάποιο γραφικό περιβάλλον . Αυτό γίνεται διότι τα πάντα γίνονται μέσω μιας mmc κονσόλας. Πληκτρολογούμε λοιπόν mmc στην γραμμή εντολών μας και έχουμε κάτι παρόμοιο με αυτό:
     

     
    Μετά την προσθήκη του εργαλείου στην κονσόλα έχουμε το πολυπόθητο γραφικό μας περιβάλλον .
     

     
     
     
     
     
     
    Το μόνο που χρειάζεται είναι να δηλώσουμε τους 2 ldap server μας και κατόπιν μπορούμε να εκτελέσουμε άφοβα κάποια παραμετροποίηση αντικειμένων στο Active Directory μας. Σε περίπτωση απώλειας κάποιου object , user, ou , group ή οποιουδήποτε άλλου αντικειμένου του Active Directory το μόνο που χρειάζεται είναι ένα κλικ στο μαγικό κουμπί Resync και όλες οι διαφορές εμφανίζονται σε μία από τις 3 καρτέλες του εργαλείου από τις οποίες μπορούμε να δούμε και να επαναφέρουμε ότι έχουμε αλλάξει από το τελευταίο Resync
     
     
     
     
     

     
    Κάτι άλλο που αξίζει να σημειωθεί εδώ είναι ότι το εργαλείο αξιοποιεί στο έπακρο το Active Directory auditing κάνοντας queries σε όλους τους DC του Domain για να εντοπίσει όλες τις αλλαγές που έχουν γίνει στο αντικείμενο χρησιμοποιώντας τα  Parallel Extensions (June CTP) της  .NET και εκμεταλλεύεται πλήρως την τεχνολογία των πολλαπλών πυρήνων.
     
     
     
     
     
     
     
  14. i-away
    A common issue when migrating to a new exchange version is the exhaustion of the log space resulting migration failures. Of course you can not simply go and delete those files because this will lead to more problems than the original one.
    One migitation to this problem is to run a full backup in order to clear the files and release the space.The other way is to enable circular logging which can be done before you start the migration in order to prevent the problem from happening in the first place.
    The migration  procedure uses the Migration  arbitration mailbox  to store migration information and causes the transaction logs that fill up the disk.
    You can find the name of the used arbitration mailbox and its database by the following powershell command:
    “Get-Mailbox -Arbitration | ft Name,Database”
    You can move those mailboxes to another Database and enable there the circular logging with the following command:
    “Set-MailboxDatabase “DatabaseName” -CircularLoggingEnabled $true”

    Happy disk space free migrations!!!!!


  15. i-away
    Σε μια κουβέντα που είχα με τον εκλεκτό συνάδερφο κ.Σίμο ετέθη το θέμα των Domain Keys στον Exchange server τόσο στην έκδοση 2010 όσο και σε παλιότερες.Η Microsoft λόγω της υποστήριξης του δικού της SPF Record όσο και του SenderID επίσημως δεν υποστηρίζει Domain Keys. ( Όσον αφορά τον Exchange 2010 μιλάμε πάντα πρό SP1 καθώς άγνωσται αι βουλαί των Developpers ).
    Παρόλα αυτά οι μεγάλοι mail hosters/providers ( Hotmail,Yahoo,Gmail, κλπ ) έχουν υιοθετήσει υποδομή τόσο Domain Key (RFC 4780)όσο και την εξέλιξη του το DKIM (RFC 4781) με αποτέλεσμα πολλά mail μας να κατάλήγουν στον spam/junk folder όταν ο παραλήπτης είναι σε τέτοιο Account.
    Η λύση για το παραπάνω πρόβλημα είναι λίγο περίπλοκη και χρονοβόρα αλλά δουλεύει σε όλους τους
    Exchange Server (2000/2003/2007 SP1 rollup 9 ή  SP2 /2010) όπως επίσης και σε όλα τα IIS SMTP Services.
    Ας δούμε όμως πρώτα πως δουλεύει η παραπάνω υποδομή:
     
    Τα Domain Keys/DKIM συνδυάζουν την κρυπτογράφηση δημόσιου κλειδιού και έναν DNS server για να παρέχουν domain-level authentication για τα email μας.
    Όταν ο αποστολέας ενός  email ισχυρίζεται ότι προέρχεται από συγκεκριμένο domain, τα DomainKeys/DKIM παρέχουν έναν μηχανισμό με τον οποίον μπορούμε να προσδιορίσουμε αν αυτό είναι αληθές ή όχι.
    Για να έχει ένα email υπογραφή DomainKeys/DKIM, θα πρέπει να έχουμε ένα ζευγάρι private key/pulic key.
    Πώς δουλεύει:
    Email sender->
    IIS SMTP Service/Exchange Server->
    DomainKeys/DKIM Sink->
    DomainKeys/DKIM Sink δημιουργεί digital signature μέσω του private key βασισμένο στο email content.->
    IIS SMTP Service/Exchange Server παραδίδει το μήνυμα.
    Remote Server received the email->
    Ελέγχει το public key απο τον DNS record του αποστολέα->
    Επαληθεύει το digital signature χρησιμοποιώντας το public key.

    Για να δουλέψουν όλα τα παραπάνω θα χρειαστεί να εγκαταστήσουμε αυτό.

    Αφού κάνουμε την εγκατάσταση ( κρατήστε μία υποσημείωση εδώ για το τέλος ) και τρέξουμε τον DomainKeys Sink Manager επιλέγουμε Setup DomainKeys/DKIM Signature->New DomainKeys. Εκεί προσθέτουμε το domain name μας όπως επίσης και έναν selector ο οποίος προτείνεται να είναι ο s1024.Αφήνουμε τα υπόλοιπα όπως είναι και πατάμε ΟΚ.

    Συγχαρητήρια μόλις δημιουργήσαμε το DomainKeys/DKIM certificate για το domain μας.

    Σειρά έχει το export το οποίο γίνεται επιλέγοντας το domain name μας και πατώντας Export Public Key αυτό μας δημιουργεί ένα Public Key και ένα TXT για τον DNS μας.

    Ας δούμε τώρα πως κάνουμε Import στον DNS μας:

    Έστω ότι το TXT μας είναι της μορφής:
    s1024._domainkey.secureitservices.eu text =

    "t=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDsu9Oe+Xq6k/SyU9dMS1hzcWj8RtjsxQ6VhLhBHoic3Fw48yaEGXiAtAJfapEKwEeVs/rF581y1pvVncIHlRjg9wp6NY3mOXBIh0Vrbklo2zqq4j4bIOtkiRkaFPjbE2WM7KmfldjhOTrzedQmbuMMFjPtUNFlpGR9Ux6zCqG1QwIDAQAB"  
    Step 1: Επιλέγουμε το  domain μας (secureitservices.eu).

    Δεξί κλίκ στο record list και επιλέγουμε "Other New Records..."

    Step 2: Επιλέγουμε το  Text (TXT) record και πατάμε "Create Record..." 
    Step 3: Εισάγουμε το  t=y; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDsu9Oe+Xq6k/SyU9dMS1hzcWj8RtjsxQ6VhLhBHoic3Fw48yaEGXiAtAJfapEKwEeVs/rF581y1pvVncIHlRjg9wp6NY3mOXBIh0Vrbklo2zqq4j4bIOtkiRkaFPjbE2WM7KmfldjhOTrzedQmbuMMFjPtUNFlpGR9Ux6zCqG1QwIDAQAB στο "Text" textbox και το "s1024._domainkey" Record Name. 
    Πατώντας ΟΚ έχουμε τελειώσει με απόλυτη επιτυχία.

     
    Η ώρα της υποσημείωσης πριν προχωρήσουμε παρακάτω:

     
    Σε πολλαπλούς servers:

    Σε περίπτωση πολλαπλών SMTP servers πρέπει να βάλουμε το certificate ώς εξής: Αφού εγκαταστήσουμε το πρόγραμμα στον πρώτο server και δημιουργήσουμε το certificate για το domain μας, εγκαθιστούμε το πρόγραμμα και στους υπόλοιπους  servers κάνοντας copy το  *.pfx certificate και αποεπιλέγοντας το "I don't have a certificate ..." .

    IIS SMTP Event Sink

    Το παραπάνω πρόγραμμα εγκαθιστά ένα event sink που ονομάζεται "EA DomainKeys Sink" στον  IIS SMTP(Exchange 2000 and Exchange 2003) OnMessageStart Event. Αυτό είναι το τελευταίο σχεδόν event πρίν ο IIS SMTP στείλει το email. Αυτό γίνεται για λόγους συμβατότητας με άλλα  SMTP plug-ins που μπορεί να υπάρχουν. Σε περίπτωση που υπάρχει μόνο αυτό το plugin προτείνεται να εγκατασταθεί στο  OnPostCategorize event, για λόγους performance.

    Σε περιβάλλον IIS SMTP Service, Exchange 2000, Exchange 2003, θα βρείτε τα "InstallOnPostCategorize.bat" και  "InstallOnMessageStart.bat" στον installation folder

    Exchange 2007 Transport-Agent

    Σε περιβάλλον Exchange 2007 εγκαθίσταται ένας transport-agent "EA DomainKeys Agent". Η παγίδα εδώ είναι ότι ο συγκεκριμένος  transport agent  πρέπει να είναι πάντα ο τελευταίος αλλιώς ο Exchange δεν δουλεύει.

     
    Πως θα ελέγξουμε ότι το έχουμε κάνει σωστά:

     
    Στέλνουμε ένα mail απο τον server μας σε ένα yahoo account.Αν ανοίξουμε το mail απο webmail και δούμε εικονίδιο με κλειδί δίπλα απο τον αποστολέα σημαίνει ότι το έχουμε κάνει σωστά και δουλεύει.

    Καλή επιτυχία!

     
    Υ.Γ ζητώ συγνώμη για την απουσία φωτογραφιών αλλά το Blog αρνείται να δεχτεί φωτογραφίες απο οπουδήποτε ( ADMIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIINS ) . Μόλις επιλυθεί το πρόβλημα θα ανέβουν και τα σχετικά screenshots.

  16. i-away
    Από την εμφάνιση του Exchange 2007 SP1 οι απανταχού admins διαμαρτυρόταν για την έλλειψη δυνατότητας Exchange-aware backup και restore μέσω του Windows Server Backup. Ό μόνος τρόπος backup ήταν μέσω του Microsoft Data Protection Manager (DPM) ή 3rd party εργαλείων.
    Τώρα με την έλευση του Service Pack 2 έχουμε ένα Exchange–aware VSS plug-in για το Windows Server Backup στον Windows Server 2008 που έρχεται να καλύψει αυτό το κενό.
    Ας δούμε όμως με απλά βήματα την διαδικασία backup-restore .

    Το περιβάλλον μας αποτελείται απο έναν απλό Exchange Server 2007 SP2 (Enterprise edition) server που τρέχει πάνω σε έναν Windows Server 2008 SP2.
    Έχουμε 6 storage groups τα οποία έχουν απο 1 database.


    Όπως βλέπουμε παρακάτω υπάρχουν 3 storage group LUNs και 3 database LUNs, πράγμα που σημαίνει ότι κάθε SG LUN έχει 2 storage groups και κάθε DB LUN 2 databases.


    Κάθε LUN έχει γίνει present στον Windows Server με drive letters. Εδώ να πω ότι η χρήση mount points προκαλούσε failure στο initial database consistency check. Περαιτέρω έρευνα αποκάλυψε ότι είναι γνωστό bug.



    Βέβαια το plugin δεν είναι πανάκεια. Έχει κάποιους περιορισμούς:
    Μπορεί να κάνει μόνο VSS-based backups. Τα Streaming backups δεν υποστηρίζονται. Τα Backups γίνονται σε επίπεδο volume. Αυτό σημαίνει ότι όλα τα data στο συγκεκριμένο volume θα γίνουν backup. Το plug-in δεν υποστηρίζει remote VSS backups. Το backup μπορεί να γίνει είτε σε τοπικό drive είτε σε κάποιο network share.Tape library δεν υποστηρίζονται.Εάν θέλουμε backup σε tape,πρέπει να χρησιμοποιήσουμε το disk to disk to tape model. Θα πρέπει να παίρνουμε full VSS backups. Επειδή το VSS plug-in δεν υποστηρίζει τον Exchange Replication VSS Writer, δεν μπορούμε να κάνουμε backups από έναν passive Exchange 2007 cluster node παρά μόνο απο τον ενεργό. Κατά το restore, μπορούμε να επιλέξουμε την αρχική τοποθεσία ή μια εναλλακτική .Εάν επιλεγεί η αρχική η διαδικασία είναι πλήρως αυτοματοποιημένη. Το VSS plug-in δεν υποστηρίζει Recovery Storage Groups.Μπορούμε βέβαια έμμεσα να κάνουμε restore σε ένα alternate location και μετά να κάνουμε create το RSG Κατά το restore, πρέπει να γίνουν restore όλα τα SGs - DBs που είναι στι ίδιο LUN. Installing the Window Server 2008 Backup Features
    Εγκαθιστώντας το Service Pack 2, το πρώτο πράγμα που πρέπει να κάνουμε μετά είναι να ενεργοποιήσουμε τις Windows Server Backup features στον Windows Server 2008. Αυτό γίνεται είτε μέσω του ServerManagerCMD.exe είτε απο την Server Manager console.


    Πατάμε “Next” και “Install”.


    “Close” και exit.


     
    Ας δούμε τώρα το Backup. Ανοίγουμε το Windows Server Backup.


    Εδώ έχουμε την επιλογή διημιουργίας backup schedule ή μεμονωμένου backup once.

    “Next”.


    Επιλέγουμε “Custom” και “Next”.


    Αποεπιλογή του “Enable system recovery” και επιλογή των SG - DB LUNs.
    “Next”.
     


    Επιλογή τοποθεσίας αποθήκευσης του backup και “Next”.

    Στο “Specify advanced option” επιλέγουμε VSS Full Backup και “Next”.

    Πατάμε το “Backup”.

    Το Windows Server Backup ξεκινάει το consistency check της database.

    Μόλις τελειώσει το consistency check ξεκινάει το backup.

    Επιβεβαιώνουμε ότι τα log files έχουν γίνει truncate.


    Επιβεβαιώνουμε ότι το last full backup property έχει γίνει was update.

    Ό έλεγχος του “Last full backup” μπορεί να γίνει και μέσω Exchange Management Shell με την εντολή Get-MailboxDatabase –Identity “DB name” –Status | FL.
    Εδώ να μην ξεχάσουμε να πάρουμε backup τα image files.Όπως βλέπουμε τα backups είναι σε VHD files μαζί με κάποια associated XML files.

  17. i-away
    Ας δούμε τώρα την διαδικασία του restore. Έχουμε 2 επιλογές είτε στην αρχική είτε στην εναλλακτική τοποθεσία.
    Για να ξεκινήσουμε το restore επιλέγουμε το “Recover” στο Action pane.

    Πατάμε “Next”.


    Επιλογή ημερομηνίας για restore και “Next”.

    Στην “Select recovery type” σελίδα, επιλέγουμε “Applications” και πατάμε “Next”.

    Στην “Select application” σελίδα επιλέγουμε τον Exchange και πατάμε στο “View Details”.
    Σε περίπτωση που κάνουμε restore το τελευταίο backup και δεν θέλουμε roll-forward recovery των databases, επιλέγουμε το παρακάτω:

    Στο “Details – Exchange” παράθυρο, βλέπουμε τα storage groups και τις databases που έχουν γίνει backup.

    Πατάμε “OK” και “Next”.
    Στο “Specify recovery options” επιλέγουμε το απευθείας restore στα production storage groups και databases ή το restore σε εναλλακτική τοποθεσία.

    Με κλίκ στο “Recover” ξεκινάει η διαδικασία.


    Κατά την διαδικασία οι databases γίνονται dismount και mount αυτόματα.

    Επίσης τα log files γίνονται restore.

  18. i-away
    Ας δούμε τώρα πως γίνεται το restore σε εναλλακτική τοποθεσία:
    Ακολουθώντας τα προηγούμενα βήματα και φτάνοντας στην οθόνη “Specify recovery options” επιλέγουμε το “Recover to another location”. Μετά αφου επιλέξουμε το LUN volume που θα κάνουμε το restore πατάμε “Next”.

    “Recover” και έναρξη της διαδικασίας.



    Μετά το τέλος έχουμε την εξής εικόνα:



    Εδώ προτού κάνουμε οτιδήποτε πρέπει να ελέγξουμε το state της database. Αυτό το κάνουμε μέσω του Eseutil με χρήση του /MH switch.
    Eseutil.exe /MH “Mailbox Database Name.edb”
    Μας εμφανίζετε ότι η database είναι σε dirty shutdown state, που σημαίνει ότι δεν μπορεί να γίνει mount πριν έρθει σε clean shutdown state.

    Για να το κάνουμε αυτό εκτελούμε την εξής εντολή:
    Eseutil /R E00 /I /dX:\Restore\F_\MDB1


    Επανέλεγχος με το Eseutil:

    Ανοίγουμε το Outlook Web Access και σβήνουμε κάποια δεδομένα:


    Ανοίγουμε την “Exchange Management Console”.Πάμε στο “Toolbox” και επιλέγουμε το “Database Recovery Management tool”.


    Βάζουμε ένα όνομα και πατάμε “Next”.

    Πατάμε “Create a recovery storage group”.

    Επιλέγουμε το storage group στο οποίο θα γίνει link το recovery storage group.
    Πατάμε “Next”.

    Στην σελίδα “Create the Recovery Storage Group” επιλέγουμε recovery storage group log, system και checkpoint file folder paths όπως και το database path και πατάμε “Create the recovery storage group”.


    Επιλέγουμε “Mount or dismount databases in the recovery storage group”.

    Επιλέγουμε την Mailbox database και πατάμε “Mount selected database”.


    Για να κάνουμε recover mailbox data, επιλέγουμε “Merge or copy mailbox content”.

    Πατάμε “Gather merge information”.

    Στην “Select Merge Options” σελίδα ορίζουμε το alias του mailbox που θα γίνουν recover τα items και πατάμε “Perform pre-merge tasks”.

    Στην σελίδα “Select Mailboxes to Copy or Merge” επιλέγουμε τα κατάλληλα mailbox και πατάμε “Perform merge actions”.


    Ανοίγοντας το mailbox βλέπουμε ότι τα σβησμένα data μας έχουν επανέρθει.

  19. i-away
    Διαβάζοντας το blog της ομάδας που αναπτύσσει τον Exchange ανακάλυψα ότι μέσα στις πληροφορίες για τον Exchange 2010 υπήρχε και ένα post που ανέφερε ότι το service pack 2 για τον Exchange 2007 θα κυκλοφορήσει το 3 τρίμηνο του 2009 .
    Απαντώντας στα πολλά παράπονα των χρηστών για την έλλειψη ενσωμάτωσης backup του exchange στο backup utility του windows server 2008 όπως μας είχε συνηθίσει στον 2003 . Στο SP2 λοιπόν εισάγεται ένα Plugin που επιτρέπει στο backup utility τον 2008 να κάνει VSS based backup τον Exchange. Βέβαια ακόμα και έτσι παρόλο που αυτή η μέθοδος είναι Exchange-aware δεν παίρνει backup ξεχωριστά τον exchange αλλά όλο το volume και δεν υποστηρίζει streaming backups
     
     

    Το καλό είναι ότι υποστηρίζεται local backup όπως επίσης και backup σε network share αλλά δεν υποστηρίζονται remote backup functions . Εδώ να αναφέρουμε επίσης ότι το Plugin του backup υποστηρίζει μόνο full backups .
    Βέβαια κατά την διαδικασία του restore μπορούμε να επιλέξουμε ( ευτυχώς ) τι θα επαναφέρουμε
     
     

     
     

     
    Η διαδικασία του restore μπορεί να γίνει με 2 τρόπους:
    In-place η οποία επαναφέρει το backup στην αρχική του τοποθεσία κάνοντας αυτόματο recover . Αυτό όμως σημαίνει ότι δεν υποστηρίζει RSG ( Recovery Storage Groups ) .
    Την υποστήριξη αυτή μας την δίνει η out-of-place διαδικασία που μας επιτρέπει να κάνουμε restore σε διαφορετική τοποθεσία και στην συνέχεια με χρήση RSG να κάνουμε την επαναφορά των αρχείων που μας ενδιαφέρουν .
    Κάτι πολύ σημαντικό είναι ότι μπορούμε να ανοίξουμε διαφορετικά backups ακόμα και αν είναι από διαφορετικούς server από αυτόν που επαναφέρουμε.
    Φυσικά δεν θα έβγαζαν ένα ολόκληρο service pack για να προσθέσουν μόνο μια λειτουργία. Σύμφωνα με το blog post “ Το service pack 2 ετοιμάζει την μετάβαση στον Exchange 2010 “ με κυριότερη μια λειτουργία που αναφέρεται ως “ dynamic Active Directory (AD) schema update and validation” η οποία θα επιτρέπει ταυτόχρονη ύπαρξη Exchnage 2007 και Exchange 2010 προφανώς σε σενάριο μετάβασης όπως επίσης υπόσχεται ευκολότερη και καλύτερη διαχείρηση των καινούργιων object που θα προστίθενται στο AD.
    Και φυσικά δεν θα μπορούσε να λείπει ένας καταιγισμός από καινούργιες Powershell εντολές ειδικά για διαχείρηση public folders , management και Monitoring μέσω powershell. Επίσης προστίθεται γραφικό περιβάλλον στο diagnostic logging και καινούργια auditing events για τα οποία όμως μέχρι στιγμής δεν έχουν ανακοινώσει περισσότερες πληροφορίες.
     
     
     
     
  20. i-away
    Μέχρι την έλευση του πολυπόθητου Exchange 2010 και των πολλών βελτιώσεων που μας φέρνει , ας ρίξουμε μια ματιά σε ένα σημαντικό troubleshooting εργαλείο του Exchange 2007 τον Exchange Server Remote Connectivity Analyzer ( για συντομία (ExRCA) ).Ο  ExRCA μας επιτρέπει το validation της  Autodiscover υπηρεσίας , το  Outlook Anywhere (γνωστό και ως RPC over HTTP) και τα inbound SMTP configuration μέσω ενός web based tool.
    Η τρέχουσα έκδοση του εργαλείου περιλαμβάνει 5 βασικές επιλογές:
    Outlook 2007 Autodiscover connectivity test
    Outlook 2003 RPC over HTTP connectivity test
    ActiveSync Autodiscover test
    ActiveSync test
    Inbound SMTP e-mail test
    Όπως βλέπουν οι περισσότερες λειτουργίες αφορούν τον Exchange Server 2007. Παρόλα αυτά μπορούν να τεστάρουμε και  RPC over HTTP τα οποία μπορεί να είναι hosted σε έναν Exchange Server 2003 box και επίσης να χρησιμοποιήσουμε το inbound SMTP e-mail test για οποιονδήποτε  SMTP server.
    Ανοίγουμε τον IE και πληκτρολογούμε  http://www.testexchangeconnectivity.com


     
    Για την παραμετροποίηση των services του  Exchange Server 2007 για εσωτερικά και εξωτερικά url όπως και για τα web services θα βρείτε χρήσιμες πληροφορίες στο Configuring Exchange Server 2007 Web Services URLs.
    Εδώ να τονίσω ότι το συγκεκριμένο  web εργαλείο μας επιτρέπει να δοκιμάσουμε valid και invalid certificates. Βέβαια κάθε test μας επιτρέπει να κάνουμε bypass το  certificate validation που σημαίνει ότι εάν χρησιμοποιούμε internal PKI ή μία  non-valid Certificate Authority μπορούμε και τότε να χρησιμοποιήσουμε το εργαλείο.
    Ας δούμε όμως λίγα πράγματα για το Autodiscover feature:
    Το Autodiscover χρησιμοποιείται μόνο απο το Outlook 2007 και το  Windows Mobile 6.1.
    Το Autodiscover δουλεύει με διαφορετικούς τρόπους για Internal και External clients.
    Κάθε internal client που ανήκει σε Active Directory θα ψάξει εκεί για ένα Service Connection Point (SCP) για να μάθει ποιός CAS server είναι διαθέσιμος για να αποκτήσει το  Autodiscover URL.
    Όλοι οι external client και οι client που δεν μπορούν να κάνουν query το Active Diretory για το SCP object θα αναζητήσουν το host record με την ονομασία autodiscover.<smtp domain>.
    Τα Autodiscover DNS Records χρησιμοποιούνται μόνο για τους external clients που σημαίνει ότι δεν χρειάζεται να προσθέσουμε autodiscover entry στον εσωτερικό μας DNS.
    Ο  ExRCA μπορεί να μας test-άρει μόνο το  external portion του  Autodiscover και κάθε external client προσπαθεί να πάρει το Autodiscover information με 4 διαφορετικούς τρόπους. Ας τους δούμε περιληπτικά:
    Ο Client προσπαθεί να βρεί το: https://domain.com/Autodiscover/Autodiscover.xml.
    Ο Client προσπαθεί να βρεί το: https://autodiscover.domain.com/Autodiscover.xml.
    Ο Client προσπαθεί να βρεί το: http://autodiscover.domain.com/autodiscover/autodiscover,  στην περίπτωση αυτή ο client χρησιμοποιεί redirection εμφανίζοντας ένα μήνυμα στον client.Αυτό συνήθως το συναντάμε σε  hosted services.
    Τέλος ,ο  client προσπαθεί να βρεί το Autodiscover SRV Record (_autodiscover._tcp.domain.com). Το Outlook 2007 ψάχνει το SRV record και το certificate για τον host που ορίζεται στο SRV. Σε αυτήν την περίπτωση το Outlook 2007 client πρέπει να είναι τουλάχιστον Service Pack 1.
    Για να δουλέψει ο ExRCA χρειαζόμαστε ένα account. Προτείνετε να χρησιμοποιήσουμε ένα dummy account έτσι ώστε μόλις τελειώσουμε τα tests να το σβήσουμε.
    Ανοίγουμε το  http://www.testexchangeconnectivity.com και επιλέγουμε το Microsoft Office Outlook 2007 Autodiscover Connectivity Test και πατάμε Next.
    Στο  Account & Test Details συμπληρώνουμε τα  E-mail address, Domain\Username και Password πεδία. Στο  Verification section, βάζουμε τα γραμματα που μας βγάζει στην αριστερή εικόνα και αφού επιλέξουμε το  box πατάμε Perform Test.


    To ExRCA χρησιμοποιεί την ίδια λογική με τον Outlook 2007 client για να τεστάρει την  Autodiscover service και γιαυτό είναι σημαντικό να γνωρίζουμε πως το Outlook βρίσκει την  Autodiscover service. Στο επάνω μέρος της σελίδας θα εμφανιστεί είτε το γνωστό μας κόκκινο Χ ( αποτυχία ) είτε το πράσινο Tick ( επιτυχία ) . Απο κάτω μπορούμε να κάνουμε expand τα Test Steps και να δούμε λεπτομερώς τις μεθόδους που χρησιμοποιήθηκαν.
    Στο παράδειγμα μας έχουμε 2  entries, η πρώτη αποτυχημένη επειδή το  https://ccc.ca/Autodiscover/Autodiscover.xml δεν ήταν  published στο domain και η δεύτερη επιτυχημένη καθώς βρέθηκε το https://autodiscover.ccc.ca/autodiscover/autodiscover.xml 


    Σε κάθε περίπτωση μπορούμε να δούμε αναλυτικά όλα τα βήματα για να καταλάβουμε που είναι το πρόβλημα.Όπως βλέπουμε στην πρώτη προσπάθεια υπήρξε αποτυχία καθώς ο host δεν βρέθηκε. Οι αναλυτικές πληροφορίες για κάθε βήμα φαίνονται στην παρακάτω φωτογραφία :
    Ο ExRCA βρήκε τον host autodiscover.ccc.ca, με δυνατότητα να δούμε την IP Address που έγινε  resolve.Εάν κάποιο Firewall rule είναι λάθος μπορούμε να διαπιστώσουμε αν το DNS record είναι σωστό αλλά ο publishing rule πρέπει να ρυθμιστεί σωστά.
    Ο ExRCA δοκιμάζει την 443 port για τον host του προηγούμενου βήματος.
    Ο ExRCA επιβεβαιώνει ότι το certificate ταιριάζει με το όνομα  autodiscover.ccc.ca
    Ο ExRCA ανακτά το XML file που περιέχει τις ρυθμίσεις του  Outlook 2007, όπως και όλα τα data ποθ χρειάζονται για την πρόσβαση σε επιπλέον υπηρεσίες όπως : Availability, OAB, and UM.


    Στο επόμενο μέρος θα δούμε πως θα δοκιμάσουμε αν το Outlook Anywhere δουλεύει όπως και τα υπόλοιπα tests που είναι διαθέσιμα.
     
     
     
     
     
     
     
     
     
  21. i-away
    Συνεχίζοντας απο το προηγούμενο post θα δούμε πως μπορούμε να κάνουμε ταυτόγχρονα το  Autodiscover και το Outlook.
    Για να δοκιμάσουμε το Outlook Anywhere πρέπει να επιλέξουμε το Perform Outlook Anywhere Test, και στο αποτέλεσμα θα δούμε το εξής κομμάτι: 


    Με expand του  Test Steps κάτω απο το Testing RPC/HTTP connectivity μπορούμε να δούμε όλα τα βήματα που κάνει το εργαλείο για να διαπιστώσει αν δουλεύει το Outlook Anywhere. Βασικά δοκιμάζει την πόρτα 443,Το αν ταιριάζει στο  SSL Certificate το όνομα που χρησιμοποιείται απο το Outlook Anywhere,κλπ.
    Επειδή χρησιμοποιούμε την πρώτη επιλογή Microsoft Office Outlook 2007 Autodiscover Connectivity Test, το  Autodiscover θα ανακαλύψει ποιό όνομα χρησιμοποείται από το Outlook Anywhere. Για να βεβαιωθούμε ότι είμαστε στην ίδια σελίδα , ανοίγουμε την  Exchange Management Console, και κάνωντας expand το Server Configuration, κάνουμε click στο  Client Access. Στην  αριστερή πλευρά θα πρέπει να δούμε τουλάχιστον 1 server με το Outlook Anywhere Enabled να έχει την τιμή True,αλλιώς θα πρέπει να κάνουμε enable το Outlook Anywhere.Εάν είναι ενεργοποιημένο κάνουμε δεξί κλίκ σε έναν απο τους CAS servers που είναι προσβάσιμοι απο το  Internet μέσω του firewall και να πάμε στο Outlook Anywhere tab.Το όνομα που ορίζεται στο External host name θα χρησιμοποιηθεί απο την  Autodiscover service και θα δοθεί στο external Outlook 2007 για να συνδεθεί εξωτερικά.


    Μπορούμε να χρησιμοποιήσουμε την πρώτη επιλογή για να δοκιμάσουμε ταυτόχρονα  Autodiscover και  Outlook Anywhere. Δεν είναι απαραίτητο να δόσουμε κάποια δεδομένα για το Outlook Anywhere επειδή τα δεδομένα έρχονται απο το Autodiscover service.
    Στην περίπτωση που έχουμε εσωτερική  PKI υποδομή μπορούμα να χρησιμοποιήσουμε την επιλογή  Ignore Trust for SSL η οποία θα μας επιτρέψει να δοκιμάσουμε το περιβάλλον μας χωρίς την ανάγκη ύπαρξης certificate απο κάποια εξωτερική  Certification Authority.
     
    Η 2η επιλογή στην κύρια σελίδα του  ExRCA είναι η δοκιμή του Outlook 2003 RPC/HTTP Connectivity, που μας επιτρέπει να δοκιμάσουμε την δυνατότητα Outlook Anywhere (πρώην  RPC over HTTP) .Αυτό το τέστ δοκιμάζει μόνο το RPC over HTTP και γιαυτό θα χρειαστεί να προσθέσουμε κάποια δεδομένα στον wizard σε σχέση με την προηγούμενη περίπτωση.
    Το τέστ μπορεί να χρησιμοποιηθεί για να δοκιμαστεί το  RPC over HTTP τόσο σε  Exchange Server 2003 όσο και σε Exchange Server 2007. Βέβαια είναι πευκολότερο να δοκιμάσουμε το  RPC over HTTP στον Exchange Server 2007 χρησιμοποιώντας την πρώτη επιλογή καθώς το e Autodiscover service παρέχει στον wizard όλες τις απαραίτητες πληροφορίες.
    Επιλέγουμε λοιπόν  Microsoft Office Outlook 2003 RPC/HTTP Connectivity Test και πατώντας  Next βλέπουμε οτι πρέπει να προσθέσουμε κάποιες έξτρα πληροφορίες που αφορούν το RPC over HTTP configuration που πρέπει να υπάρχει στους Outlook clients. Αφού το κάνουμε αυτό το επόμενο βήμα έιναι το Perform Test.




    Το αποτέλεσμα θα έχει αναλυτικά όλα τα βήματα που ακολούθησε το εργαλείο για να συνδεθεί μέσω  RPC over HTTP στον Exchange Server .Βλέποντας στο τέλος του Log μπορούμε να δούμε αν έγινε επιτυχές  ping του εσωτερικού server όπως και τα credential που χρησιμοποιήθηκαν για την πρόσβαση στο Information Store. 


    Σε περίπτωη που χρησιμοποιήσουμε κάποιο dummy account και ενεργοποιήσουμε το Hide from Exchange Address Lists θα πάρουμε το παρακάτω λάθος.


     
    Για το  Windows Mobile 6.1 που μπορούν να χρησιμοποιήσουμ το  Autodiscover service μπορούμε να χρησιμοποιήσουμε την ίδια μέθοδο με το  Outlook 2007.




    Στην κύρια σελίδα του ExRCA επιλέγουμε  Microsoft Exchange ActiveSync Autodiscover Test και πατάμε Next. Συμπληρώνουμε τα user credentials .Εδώ μπορούμε να κάνουμε τέστ το ActiveSync connection με τον Server επιλέγοντας το Perform Exchange ActiveSync Test.
    Το αποτέλεσμα του τέστ φαίνεται παρακάτω.

     
    Μπορούμε να δοκιμάσουμε το ActiveSync χωρίς τις πληροφορίες από το Autodiscover όπως ακριβώς περιγράψαμε παραπάνω.Το αποτέλεσμα θα είναι αυτό τις παρακάτω εικόνας.


     
    Η τελέυταία επιλογή είναι η δοκιμή του inbound SMTP μέσω των παρακάτω βημάτων:
    Χρήση του  nslookup για να βρεθεί το MX record του συγκεκριμένου domain.
    Αποστολή δοκιμαστικού μηνύματος χρησιμποιώντας telnet στην πόρτα port 25 για κάθε  MX recorded που θα βρεθεί απο το προηγούμενο.Για την χρήση του telnet όσον αφορά το  SMTP communication υπάρχουν πληροφορίες στο KB 153119.
    Αυτό το τέστ δεν απαιτεί γιατί αφορά όλους τους  SMTP server.
    Επιλεγουμε Inbound SMTP Email Test και πατάμε  Next. Βάζουμε ένα valid e-mail address και τον  verification code, και πατάμε Perform Test. Το αποτέλεσμα φαίνεται παρακάτω


    Αν όλα πάνε καλά θα δούμε στο inbox μας ένα μήνυμα με το MX record που χρησιμοποιήθηκε όπως και την διεύθυνση που βάλαμε στο  ExRCA.

     
     
     
     
     
     
     
     
     
     
  22. i-away
    Με την έλευση του Exchange 2007 SP1 εμφανίστηκε ένα νέο feature γνωστό ως Standby Continuous Replication (SCR). Το SCR αναπτύχθηκε κυρίως για εφαρμογή σε site resilience σενάρια. Το ήδη υπάρχον CCR feature βελτιώθηκε έχοντας πλέον την δυνατότητα να έχει τα Windows failover cluster nodes σε διαφορετικά subnets. Παρόλα αυτά υπήρξε η απαίτηση να αναπτυχθούν multi-site CCR clusters σε μεγάλες εγκαταστάσεις Exchange . Το multi-site CCR cluster είναι η βέλτιστη λύση έαν έχουμε την κατάλληλη υποδομή που το υποστηρίζει . Βέβαια είναι ένας πραγματικός εφιάλτης έαν πάμε να το υλοποιήσουμε σε μια τοπολογία που δεν το υποστηρίζει ( Λέγε με σωστό Planning ).
    Η αμέσως επόμενη λογική ερώτηση είναι σε τι λειτουργικό σύστημα είναι το καλύτερο να το βάλω. Φυσικά σε Windows 2008 ή 2008 R2 ( Αναβαθμίστε , αναβαθμίστε , αναβαθμίστε ) .
    Μεταξύ των βελτιώσεων του CCR συγκαταλέγεται η υποστήριξη για multi-subnet failover clusters και ταχύτερο log file shipping. Όπως γνωρίζουμε η Exchange Replication Service χρησιμοποιεί SMB για το log file shipping. Στα Windows Server 2008 έχουμε την εμφάνιση του SMB v2, το οποίο βελτιώνει κατά 30-40% την ταχύτητα σε σχέση με το SMB.
    Η εγκατάσταση των Windows 2008 Failover Cluster είναι ευκολότερη σε σχέση με αυτή των Windows Server 2003. Επιπλέον είναι γνωστό ότι το in-place upgrade των Windows Server 2003 based Exchange 2007 servers σε Windows Server 2008 θα είναι αδύνατη και θα πρέπει να αντικαταστήσουμε τους υπάρχοντες servers με Windows Server 2008 based Exchange 2007 SP1 servers.
    Εάν εγκαθιστούμε multi-site CCR cluster nodes σε Windows Server 2003 τα cluster nodes πρέπει να βρίσκονται στο ίδιο subnet γιατί δεν υπάρχει υποστήριξη εύρεσης cluster nodes σε διαφορετικά subnets. Σε αυτή την περίπτωση πρέπει να αναδιοργανώσουμε τα subnets μας που σημαίνει ότι το broadcast traffic ( heartbeat ) θα γίνεται μέσω WAN μεταξύ των σημείων μας .
    Με χρήση Windows Server 2008 η αναδιοργάνωση των subnets εφόσον τα Windows Server 2008 παρέχουν πλήρη υποστήριξη για routed networks. Όπως βλέπουμε έχουμε δυνατότητα να ορίσουμε 2 IP addresses για το Windows Server 2008 Failover Cluster


    Μπορούμε να δούμε την δομή μας. Το σχέδιο η τοπολογία εξαρτάται απο την υλοποίηση ( ίδιο ή διαφορετικό subnet ,όνομα , κλπ).


    Για την διημιουργία μιας αναφοράς κάνουμε δεξί κλικ στο network name του cluster και επιλέγουμε Dependency Report


    Όταν το Windows Server 2008 Failover Cluster έχει διημιουργηθεί και εγκαθιστούμε τον Exchange 2007 Active Mailbox ρόλο, έχουμε την δυνατότητα να ορίσουμε την IP address που θα γίνει assigned στον Clustered Mailbox Server (CMS) σε κάθε subnet.


    Αν και μπορούμε να εγκαταστήσουμε τους Active και Passive Mailbox server ρόλους μέσω του Exchange 2007 Setup wizard είναι προτιμότερο να χρησιμοποιήσουμε το command line όταν εγκαθιστούμε έναν νέο CMS ( Ναι δυστυχώς δεν τα κάνει όλα το setup μόνο του ).Η εγκατάσταση γίνεται μέσω της ακόλουθης εντολής:
    Setup.com /Mode:install /Roles:mailbox /NewCMS /CMSName:<CMS name> -CMSIPv4Addresses:<IP1>,<IP2>
    Και για την εγκατάσταση του Passive Mailbox:
    Setup.com /Roles:mailbox


    Ώς best practice προτείνονται 4 ή περισσότερες κάρτες δικτύου σε κάθε CCR cluster node. Συνήθως προτιμούνται 5 με την εξής διάταξη:
    - 2 κάρτες σε WAN team (μόνο για fault tolerance και χωρίς load balance διότι παρουσιάζουν τυχαία κολήματα ).
    - 2 κάρτες για log shipping (log shipping redundancy).
    -1 κάρτα ως backup (disabled για cluster use) εφόσον δεν θέλουμε backups μέσω WAN.
    Το παραπάνω design μας προσφέρει 3 ανεξάρτητα paths για replication και 3 ανεξάρτητα paths για heartbeat επικοινωνία μεταξύ των cluster nodes.
    Καλό θα ήταν επίσης να ονομάσουμε τις κάρτες μας για να μην μπερδευόμαστε όπως φαίνεται παρακάτω.


     
    Προσοχή χρειάζεται και το Scalable Networking pack feature ειδικά όταν έχουμε Windows 2003 based Exchange 2007 servers Για περισσότερα στο: http://msexchangeteam.com/archive/2007/07/18/446400.aspx.
    Ασχέτως αν χρησιμοποιούμε Windows Server 2003 ή Windows Server 2008 τα CCR cluster nodes πρέπει να βρίσκονται στο ίδιο Active Directory (AD) site.Το πρόβλημα εδώ είναι ότι ενώ τα Windows Server 2008 Failover Clusters υποστηρίζουν nodes διαφορετικών AD sites, ο Exchange δεν μπορεί να τα κάνει locate.
    Επειδή τα CCR cluster nodes πρέπει να ανήκουν στο ίδιο AD site τα μηνύματα μεταξύ των χρηστών που έχουν mailbox στον CMS του primary datacenter θεωρητικά μπορούν να αποσταλούν και να ληφθούν απο τους Hub Transport (HT) servers του backup datacenter. Το ίδιο ισχύει και για τα Exchange client requests ( Autodiscover, OWA, EAS, POP3, και IMAP ). Επιπλέον τα DAP/auth requests στους Global Catalog servers (GCs) μπορούν να εξυπηρετηθούν απο το backup datacenter. Αυτό έχει ως αποτέλεσμα τεράστιο traffic λόγω της MAPI over RPC επικοινωνίας .
    Αυτό βέβαια μπορεί να ελεγχθεί μέσω της εντολής Set-MailboxServer cmdlet μαζί με την παράμετρο -SubmissionServerOverrideList που καθορίζει ποιοί Hub Transport servers θα χρησιμοποιούνται.Σε περίπτωση disaster απλά κάνουμε update την submission override list
    Για να μπλοκάρουμε τα CAS server requests/connections εκμεταλευόμαστε τους load balancing μηχανισμούς . Σε μεγάλα περιβάλλοντα όπου θα έχουμε υλοποιήσει hardware based ή WNLB based λύση τα βήματα που ακολουθούμε είναι τα εξής:
    Διημιουργούμε ένα NLB array με όλους τους CAS servers του primary datacenter. Ρυθμίζουμε την internal URL για Autodiscover, OWA, OAB, EWS και UM να δείχνει στο FQDN όνομα (namespace.company.com) του load balancing solution. Κάνουμε ένα δεύτερο NLB array για τους CAS servers του backup datacenter, uχρησιμοποιούμε το ίδιο FQDN αλλά διαφορετική IP address απο την πρώτη και προσέχουμε να υπάρχουν μοναδικές εγγραφές στον DNS Για τους GCs, ρυθμίζουμε τους Outlook clients να χρησιμοποιούν GCs στο primary datacenter. Using two Active Directory Sites in the Backup Datacenter Για να αποφύγουμε οι servers και clients του primary datacenter να επικοινωνούν με τους Exchange 2007 servers και GCs του backup datacenter, μπορούμε να διημιουργήσουμε ένα επιπλέον AD site στο backup datacenter και να μετακινήσουμε όλους τους servers εκτός των Windows Failover Cluster στον οποίο έχουμε τον Mailbox role.


    Σε περίπτωση disaster στο the primary datacenter αυτό που πρέπει να γίνει είναι η μετακίνηση των servers απο το δεύτερο AD site στο πρώτο AD site με αλλαγές IP address ή με αλλαγή των AD site definitions στο Active Directory Sites and Services. Εδώ να σημειώσουμε ότι η απλή μετακίνηση του CMS στο δεύτερο AD site δεν θα επιτρέπει στον HT server το re-submit των μηνυμάτων στον CMS πράγμα που θα επιφέρει data loss.
    Προσοχή χρειάζεται επίσης στην διατήρηση του network latencyσε επίπεδα κάτω των 500 milliseconds (ms).Τα default tolerance settings για τα missed cluster heartbeats είναι ρυθμισμένα στον αριθμό 5 missed heartbeats για τα nodes ίδιου subnet ή διαφορετικού subnets.Σε περίπτωση multi-site clusters προτείνεται αλλαγή σε 10 missed heartbeats (περίπου 12 seconds).


    Για την αλλαγή του CrossSubnetThreshold threshold εκτελούμε την παρακάτω εντολή:
    cluster ClusterName /prop CrossSubnetThreshold=10
    Μπορούμε να επιβεβαιώσουμε την παραπάνω εντολή με το :
    Cluster.exe /cluster:<ClusterName> /prop


     
    Όταν συμβαίνει μετακίνηση του CMS από ένα cluster node σε ένα άλλο cluster node και η IP address και το network resource name επανέλθουν online , το failover cluster ξεκινάει έναν timer. Μετά από 10 minutes αποστέλεται ένα DNS.
    Από default το DNS Time to Live (TTL) value για το network name resource είναι 20 λεπτά .Αυτό σημαίνει ότι θα χρειαστεί αρκετός χρόνος για το update όλων των domain controllers όπως και για την resolver cache των Outlook clients.


    Το best practice είναι η αλλαγή του DNS TTL value στα 5 λεπτά. Για να το κάνουμε αυτό πρέπει πρώτα να βρούμε το CMS cluster network name resource. Αυτό γίνεται μέσω της εντολής:
    cluster /cluster:<Name of CMS> res


    Τώρα μπορούμε να αλλάξουμε το TTL σε 5 λεπτά:
    Cluster.exe res <CMSNetworkNameResource> /priv HostRecordTTL=300


    Ακολουθεί επανεκίνηση του Clustered Mailbox Server (CMS) μέσω των εντολών Stop-ClusteredMailboxServer και Start-ClusteredMailboxServer .Να σημειώσουμε ότι η αλλαγή του DNS TTL μέσω των ιδιοτήτων του DNS record δεν είναι δυνατή καθώς η ρύθμιση θα γίνει overwrite απο την τιμή που είναι ρυθμισμένη για το HostRecordTTL κάθε φορά που ο CMS ξεκινάει,μετακινείται ή επανέρχεται online.
    Για την επιβεβαίωση της αλλαγής του TTL για το DNS record ανοίγουμε τις ιδιότητες του CMS cluster network name resource DNS record στον DNS Manager.



    Σε περίπτωση disaster στο primary datacenter όλοι οι servers θα είναι unavailable και όλα τα messages θα κρατηθούν στα transport dumpster των Hub Transport servers, χωρίς να μπορούν να γίνουν re-submitted στον CMS μετά το failover στον passive cluster node του backup datacenter. Βέβαια είναι δυνατόν να μετακινήσουμε το queue ενός HT server σε έναν HT server στο backup datacenter και να επιτύχουμε έτσι το re-submittion του queue. Αυτό βέβαια πρέπει να γίνει πριν το cluster δώσει την εντολή για το transport dumpster flush.
    Ένα CCR based cluster χρησιμοποιεί το Node majority με File Share Witness (FSW) quorum μοντέλο. Σε αυτό τον τύπο του quorum , δύο nodes δεν είναι αρκετά σε περίπτωση failure ενός cluster node. Για να καταστεί αυτό δυνατό πρέπει να υπάρχουν τουλάχιστον 3 devices που να μπορούν να θεωρηθούν διαθέσιμες. Ο FSW λειτουργεί ως η 3η διαθέσιμη device σε ένα two-node Node majority με File Share Witness (FSW) quorum cluster. Επίσης ο FSW προστατεύει ενάντια στο cluster “split brain” syndrome και σε ένα πρόβλημα γνωστό ως “partition in time”.Η χρήση Hub Transport server ως FSW αποτελεί best practice όταν υιοθετούμε το παραπάνω μοντέλο.
    Η χρήση CNAME record για υπόδειξη του FSW απλοποιοιέι τα πράγματα σε περίπτωση ανάγκης υπόδειξης 2ου FSW. Το μόνο που χρειάζεται είναι να προυπάρχει ένα pre-created FSW folder και μια ενημέρωση του CNAME record.Σήμερα μπορούμε να χρησιμοποιήσουμε το Cluster service’s built-in “force quorum”.
    Σε περίπτωση disaster το failover δεν θα γίνει αυτόματα γιατί χρειάζονται 2 votes σε ένα MNS based cluster. Για να ενεργοποιήσουμε τα cluster resources online στον passive node, πρώτα διημιουργούμε ένα νέο FSW share στον HT server του backup datacenter ακολουθώντας αυτές τις οδηγίες, και μετά με την εντολή :
    NET START CLUSSVC /forcequorum
    ενεργοποιούμε την cluster service.Ανοίγωντας την Failover Cluster console και επιλέγοντας το cluster name επιλέγουμε Configure Cluster Quorum Settings .

    Στα Windows 2003 το /forcequorum switch έχει έναν maintenance mode switch. Στα Windows Server 2008 η παραπάνω εντολή λέει στο cluster ότι το configuration σε αυτό το node είναι το master. Όταν το failed node επανέρθει θα κάνει replicate το configuration information απο αυτό το node.


    Πατάμε Next.


    Επιλέγουμε Node and File Share Majority (για clusters με ειδικό configurations) και πατάμε Next.


    Πατάμε Browse και βάζουμε το όνομα του HT server που βρίσκεται το FSW share. Επιλέγουμε Show Shared Folders και διαλέγουμε το FSW share. Πατάμε OK.


    Next - Next – Finish .


    Όταν επανέλθει το primary datacenter διημιουργούμε ένα νέο FSW share στον παλιό HT server που είχε το FSW share και κάνουμε point το cluster σε αυτό το FSW share.
    Όταν όλοι οι servers έρθουν online στο primary datacenter, μπορούμε να μεταφέρουμε τον CMS πίσω στο primary datacenter.Δυστυχώς όμως δεν υποστηρίζεται ο συνδυασμός FSW με DFS.
     
     
     
     
     
     
     
     
     
     
  23. i-away
    You've been asking us about an Exchange 2010 version of the popular Exchange 2007 Component Architecture poster. We're pleased to let you know that the Exchange Server 2010 Architecture Poster is now available for download in all its 36" x 24" goodness! Here's a preview:

    The poster helps you understand how the major components of Exchange 2010 work and serves as a quick reminder and a learning tool. The printed version also looks really impressive on your wall!
    Head over to the Download Center to download the Exchange Server 2010 Architecture Poster (PDF).
    Those of you headed to Berlin for TechEd Europe next month, you'll be able to pick up your very own full-size glossy version from the Unified Communications booth. Wir sehen uns in Berlin!
  24. i-away
    Ο Exchange 2010 έχει διάφορα " κρυμμένα " built-in εργαλεία με τα οποία μπορούμε να κάνουμε πολλά και θαυμαστά πράγματα. ( πχ. Get-MailboxDatabaseCopyStatus , Test-ReplicationHealth , CollectOverMetrics.ps1 - CollectReplicationMetrics.ps1 )
    Σήμερα θα δούμε ένα απο τα πιό χρήσιμα scripts το CheckDatabaseRedundancy.ps1. Όπως μπορείτε να καταλάβετε απο το όνομα του το συγκεκριμένο script παρακολουθεί την κατάσταση μιας replicated mailbox database ελέγχοντας εάν υπάρχουν 2 τουλάχιστον υγιή αντίγραφα. και μας ειδοποιεί σε αντίθετη περίπτωση.
    Το output που λαμβάνουμε έχει την μορφή:
    [PS] CheckDatabaseRedundancy.ps1 -MailboxDatabaseName "Mailbox Database TestDB01"

    DatabaseName : Mailbox Database TestDB01
    LastRedundancyCount : 0
    CurrentRedundancyCount : 2
    LastState : Unknown
    CurrentState : Green
    LastStateTransitionUtc : 14/11/2010 6:51:19 AM
    LastGreenTransitionUtc : 14/11/2010 6:51:19 AM
    LastRedTransitionUtc :
    LastGreenReportedUtc : 14/11/2010 6:51:19 AM
    LastRedReportedUtc :
    PreviousTotalRedDuration : 00:00:00
    TotalRedDuration : 00:00:00
    IsTransitioningState : True
    HasErrorsInHistory : False
    CurrentErrorMessages :
    ErrorHistory :
    Ένα απο τα πλεονεκτήματα του συγκεκριμένου scripts είναι ότι με την προσθήκη της MonitoringContext παραμέτρου μπορεί να χρησιμοποιηθεί από τον Microsoft System Center Operations Manager (SCOM). Σε monitoring mode το script εμφανίζει red και green alerts στο Application event log. Το κόκκινο (event ID 4113) alert εμφανίζεται όταν μια βάση είναι "red" για 20 ή παραπάνω λεπτά ενώ το πράσινο (event ID 4114) όταν η βάση είναι "green" για 10 συνεχόμενα λεπτά.
    Υπάρχουν κάποιες πρόσθετες παράμετροι που μπορούμε να ενσωματώσουμε στο script. Για παράδειγμα η ShowDetailedErrors που μας δίνει αναλυτικότερες πληροφορίες για τα error που προκύπτουν και η επίσης πολύ χρήσιμη SendSummaryMailTos που μας ενημερώνει μέσω email για οποιοδήποτε γεγονός.
    Το script προτείνεται να τρέχει σε τακτά χρονικά διαστήματα για λόγους ελέγχου.Η ρύθμιση γίνεται μέσω της TerminateAfterDurationSecs παραμέτρου με τιμές -1 και 0.
    CheckDatabaseRedundancy.ps1 -MonitoringContext -SleepDurationBetweenIterationsSecs:0 -TerminateAfterDurationSecs:1 -SuppressGreenEventForSecs:0 -ReportRedEventAfterDurationSecs:0 -ReportRedEventIntervalSecs:0 -ShowDetailedErrors

    Αυτό βέβαια σε περίπτωση που δεν έχουμε κάποια monitoring λύση ( SCOM ). Φυσικά μπορούμε να το ενσωματώσουμε ως scheduled task.
    schtasks /create /TN "Check Database Redundancy" /TR "Powershell.exe -NonInteractive -WindowStyle Hidden -command 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; C:\Operations\CheckDatabaseRedundancy.ps1 -MonitoringContext -ShowDetailedErrors -SummaryMailFrom:'SMTPFromAddress@(domain-name)' -SendSummaryMailTos:@('SMTPToAddress@(domain-name)') -ErrorAction:Continue" /RU SYSTEM /SC HOURLY
    Γιαυτούς που βαριούνται να γράφουν μπορούν να κατεβάσουν το XML αρχείο, και να το εισάγετε στον Task Scheduler. Όπως επίσης και το script από εδώ.

  25. i-away
    Η μέχρι τώρα παρούσα τεχνολογία που χρησιμοποιούνταν στις CCR και SCR λειτουργίες, εξακολουθεί να χρησιμοποιείται και στον Exchange 2010. Η τεχνολογία αυτή εξελίχτηκε και βελτιώθηκε έτσι ώστε να υποστηρίζει νέες high availability features όπως database copies, database mobility, και database availability groups.
    Λόγω της αφαίρεσης των storage groups από τον Exchange 2010, το continuous replication πλέον δουλεύει σε επίπεδο database. Ο Exchange 2010 χρησιμοποιεί την Extensible Storage Engine (ESE) database η οποία δημιουργεί transaction logs που γίνονται replicated σε μία ή περισσότερες τοποθεσίες και γίνονται replay σε ένα ή περισσότερα αντίγραφα της mailbox database. Η μεταφορά των Log δεν γίνεται πλέον μέσω του Server Message Block (SMB). Αντίθετα ο Exchange 2010 χρησιμοποιεί administrator-defined TCP ports για το data transfer. Επιπρόσθετα ο Exchange 2010 ενσωματώνει επιλογές για network encryption και compression για το data stream. Τα Database copies αφορούν μόνο τις mailbox databases. Για λόγους redundancy και high availability των public folder databases, προτείνεται η χρήση public folder replication.Σε αντίθεση με την CCR, στην οποία πολλαπλά αντίγραφα της public folder database δεν μπορούσαν να υπάρχουν στο ίδιο cluster, μπορούμε να χρησιμοποιήσουμε το public folder replication για το replicate των public folder databases μεταξύ servers σε ένα DAG.  
    Η νέα ιδέα των Database Availability Group (DAG) στον Exchange 2010 προσφέρει χαμηλότρο κόστος με υψηλότερη διαθεσιμότητα χωρίς την ανάγκη χρήσης πανάκριβων υποδομών SAN.
     

     
     
    Οι Microsoft Exchange Server 2010 clients συνδέονται στους Client Access Servers, οι οποίοι prox-άρουν τα requests στον client. Χωρίς την ανάγκη πλέον των LCR, SCR, ή CCR…DAG ( Super CCR) με χρήση χαμηλού κόστους DAS storage για την υλοποίηση “Raid 5” των databases σε πολλαπλούς servers. Οι Client Access Servers θα παρέχουν HTTP και το νέο “distributed RPC endpoint” για τα Office 2010, Office 2007, Office 2003 εξομείωση του “standard exchange mailbox server” χωρίς την ανάγκη αναβάθμισης των clients.
    Εφόσον οι clients συνδέονται στους CAS servers που prox-άρουν τα requests στους mailbox servers, το failover απο έναν mailbox server σε έναν άλλον στην ίδια DAG γίνεται σε λιγότερο απο 30 seconds.
    Σε αυτό το σημείο ας δούμε κάποια σημαντικά σημεία της αρχιτεκτονικής της Exchange 2010 database και του HA :
    Το Replication μεταξύ των databases αλλάζει από RPC σε TCP socket πράγμα που συνεπάγεται αύξηση των επιδόσεων στους servers με μεγάλο φορτίο. Το Replication μπορεί να είναι τοπικό ή απομακρυσμένο (cross-subnet). Παρόλα αυτά θα χρειαστούμε CAS servers στο DR site εάν χάσουμε το primary datacenter. Η ύπαρξη μέχρι 16 mailbox servers σε ένα DAG. Δεν θα υπάρξει integration με το Microsoft Online σε επίπεδο DAG. Το Microsoft Online δεν μπορεί να χρησιμοποιηθεί ως DR site για ένα εσωτερικά hosted mailbox. Αυτό είτε θα είναι on-premise είτε hosted και όχι μείγμα τους. Η ύπαρξη Windows Server 2008 Enterprise, εφόσον απαιτείται η failover clustering feature Η έννοια των Storage groups υποβαθμίζεται. Η χρήση της γνωστής Jet engine για τις databases. Μείωση του Exchange IO 50% απο τον Exchnage 2007 στον 2010 (προσθήκη στην υπάρχουσα βελτίωση του 70% απο τον Exchange 2003 στον 2007). Το Single Instance Storage εξαφανίζεται όπως και το per database table. Ένα νέο table διημιουργείται για κάθε mailbox, επιτρέποντας ακόμα και 10,000+ messages σε κάθε mailbox λόγω της sequential read δυνατότητας. Τα Server based PST files επιτρέπουν το archiving με το anywhere access.  
    Οι Public folders δεν καλύπτονται απο τις νέες DAG αλλαγές και ο μόνο τρόπος να γίνουν replicate παραμένει ο ίδιος όπως παλιά δηλαδή μέσω SCR replication. Επίσης οι χρήστες θα συνεχίσουν να συνδέονται στους public folders των mailbox servers της DAG απευθείας.Οι Public Folders θεωρούνται πλέον απο την Microsoft legacy πλατφόρμα και κατόπιν τούτου αν και θα διατηρηθούν στον 2010 δεν προβλέπονται σημαντικές αλλαγές η βελτιώσεις στην λειτουργία τους.
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
     
×
×
  • Create New...