GAPTHEGURU

Geek with special skills

Enterprise Voice Server-Side Components

When you choose to deploy Enterprise Voice, you need to plan to deploy an Office Communications Server 2007 R2 Mediation Server, which intermediates signaling and media between your internal Communications Server infrastructure and your media gateway or Session Initiation Protocol (SIP) trunk. You will also need a media (IP/PSTN) gateway to handle calls between Voice over IP (VoIP)-enabled users and the public switched telephone network (PSTN). (A media gateway is not required for a SIP trunk connection.)

Media Gateway

The number, size, and location of media gateways are perhaps the most important and potentially costly decisions you must make when planning your Enterprise Voice infrastructure. The main questions to answer are:

  • What type of gateway should you deploy?
  • How many media gateways are needed? The answer depends at least in part on the size of the gateways and where you plan to deploy them.
  • What size should the gateways be? The answer depends in part on how many you plan to deploy and where you plan to put them.
  • Where should the gateways be located? The answer depends in part on the topology and geographic distribution of your organization.

In other words, no one of the previous questions can be answered independently of the other three. Answers to all four depend ultimately on how much telephone traffic you anticipate and how that traffic is distributed across your organization. But that is only the beginning: the base data, so to speak. You must also consider your gateway topology options.

Type of Gateway to Deploy

Communications Server offers three options for deploying a Mediation Server and media gateway:

  • Basic. This option consists of a basic media gateway and a separate Mediation Server.
  • Basic Hybrid. This option is a basic-hybrid gateway, in which the basic gateway and Mediation Server are collocated on a single computer.
  • Advanced. This option is an advanced media gateway, in which the Mediation Server logic is incorporated within the gateway software itself.

Table 1. Basic and Collocated Gateways Compared

Gateway Type Advantages Disadvantages
Basic Media Gateway Existing hardware can perhaps be used for Mediation Server. Mediation Server entails additional overhead for installation, configuration, and management.
Basic Hybrid Media Gateway Does not require separate Mediation Server.

Installation, configuration, and management are simpler than they are for combination of Basic Media Gateway and Mediation Server.

None.
Advanced Media Gateway Does not require separate Mediation Server. Installation, configuration, and management are simpler than they are for other gateway types. None.

Gateway Topologies

When attempting to answer the four fundamental questions of gateway deployment, the obvious approach is to:

  • Count the sites at which your organization has offices.
  • Estimate the traffic at each site.
  • Deploy one or more gateways at each site to handle the anticipated traffic.

The resulting distributed gateway topology is shown in the following figure.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Figure 1. Distributed gateway topology

With this topology, calls among workers at each site and between the sites are all routed over the company intranet. Calls to the PSTN are routed over the enterprise IP network to the gateways that are closest to the location of the destination numbers.

But what if your organization supports dozens or hundreds or even thousands of sites spread across one or more continents, as many financial institutions and other large enterprises do? In such cases deploying a separate gateway at each site is impractical.

To address this problem, many large companies prefer to deploy one or a few large telephony data centers, as shown in the following figure.
Figure 2. Telephony data center topology

In this topology, several large gateways sufficient to accommodate the anticipated user load are deployed at each data center. All calls to users in the enterprise are forwarded by the company’s telephone service provider to a data center. Routing logic at the data center determines whether the call should be routed over the intranet or to the PSTN.

Placing a gateway at every site on the one hand or at a single data center on the other represents the extremes of a deployment continuum. You can deploy single gateways at several sites and several gateways at a data center in nearly any possible combination. The best solution in each case depends on a variety of factors that are specific to each organization.

Gateway Location

Gateway location may also determine the types of gateways you choose and how they are configured. There are dozens of PSTN protocols, none of which is a worldwide standard. If all your gateways are located in a single country/region, this is not an issue, but if you locate gateways in several countries/regions, each must be configured according to the PSTN standards of that country/region. Moreover, gateways that are certified for operation in, say, Canada, may not be certified in India, Brazil, or the European Union.

Gateway Size and Number

The media gateways that most organizations will consider deploying range in size from 2 to as many as 960 ports. (There are even larger gateways, but these are used mainly by telephone service providers.) When estimating the number of ports your organization requires, use the following guidelines:

  • Light telephony users (one PSTN call per hour) should allocate one port for every 15 users. For example, if you have 20 users, you will require a gateway with two ports.
  • Moderate telephony users (two PSTN calls per hour) should allocate one port for every 10 users. For example, if you have 100 users, you will require a total of 10 ports allocated among one or more gateways.
  • Heavy telephony users (three or more PSTN calls per hour) should allocate one port for every five users. For example, if you have 47,000 users, you will require a total of 9,400 ports allocated among at least 10 large gateways.
  • Additional ports can be acquired as the number of users or amount of traffic in your organization increases.

For any given number of users you must support, you have the choice of deploying fewer, larger gateways, or smaller ones. As a rule, a minimum of two gateways for an organization is recommended in the event one goes down. Beyond that, the number and size of gateways that an organization deploys are going to vary widely, based on a careful analysis of each organization’s volume of telephone traffic.

Each basic media gateway that you deploy must have at least one corresponding Mediation Server. It is possible, though not recommended, to point a single gateway to multiple Mediation Servers, but you cannot point a single Mediation Server to more than one media gateway.

SIP Trunking

Office Communications Server 2007 R2 enables an enterprise to connect its voice network to a service provider offering PSTN origination and termination, which can simplify and reduce the cost of deploying Enterprise Voice. This capability, a variety of what is known in the telecommunications industry as “SIP trunking”, means that enterprises do not need to deploy IP-PSTN gateways, with or without Mediation Servers, in order to enable PSTN connectivity.

The Office Communications Server 2007 R2 Session Initiation Protocol (SIP) trunking capability enables the following scenarios:

  • An enterprise user inside or outside the corporate firewall can make a local or long-distance call specified by an E.164-compliant number that is terminated on the PSTN as a service of the corresponding service provider.
  • Any PSTN subscriber can contact an enterprise user inside or outside the corporate firewall by dialing a Direct Inward Dialing (DID) number associated with that enterprise user.

Exchange Unified Messaging

If your organization also plans to use Exchange Server 2007 SP1 Unified Messaging, you must deploy the following Exchange Server 2007 SP1 server roles: Unified Messaging, Hub Transport, Client Access, and Mailbox. These server roles can be deployed in the same or a different forest as Communications Server 2007 R2.

New Configuration Options in Mediation Server

Office Communications Server 2007 R2 introduces two new Windows Management Instrumentation (WMI) settings for Mediation Server. The first new setting specifies how Mediation Server processes E.164 numbers in outbound calls. The second new setting enables Quality of Service (QoS) marking on Mediation Server.

Handling E.164 Numbers in Outbound Calls

By default, E.164 numbers in the Request Uniform Resource Identifier (URI) for outgoing calls are prefixed with a plus sign (+). Most Private Branch eXchanges (PBXs) process such numbers without problem. Certain PBXs, however, do not accept numbers that are prefixed with a plus sign.

To ensure interoperability with these PBXs, Mediation Server has a new WMI Boolean setting called RemovePlusFromRequestURI, which has two values: TRUE and FALSE. If your PBX does not accept numbers prefixed with a plus sign, the value for the WMI setting should be set to TRUE, which causes Mediation Server to strip the plus sign from a Request URI for outbound calls. The default is FALSE, which causes Mediation Server to pass the outgoing INVITE’s Request URI, To URI, and From URI unchanged.

Enabling QoS on Mediation Server

Mediation Server has a new WMI Boolean setting called QoSEnabled, which has two values: TRUE and FALSE. This setting enables or disables QoS marking on Mediation Server. When set to TRUE, the setting causes Mediation Server to perform Differentiated Services Code Point (DSCP) marking on voice packets. The default value is FALSE.

In a network that has been properly provisioned for voice transmission, packet prioritization is not necessary. However, if you are unsure of bandwidth capacity, this QoS setting assures good voice quality even in suboptimal environments.

Improved Handling of Private (Non-DID) Numbers

Two improvements for handling private (non-DID) numbers in Office Communications Server 2007 R2 enable:

  • Compatibility with PBXs or other downstream elements that do not support the plus sign in Request URIs.
  • Support for private numbering plans, in which the msRTCSIP-Line property in Active Directory Domain Services (AD DS) does not have to be in E.164 format.

Compatibility with PBXs That Do Not Support the Plus Sign

By default, E.164 numbers in the Request URI of outgoing calls from Office Communications Server 2007 R2 are prefixed with a plus sign. Most PBXs process such numbers without problem. Some PBXs, however, do not accept numbers that are prefixed with a plus sign and do not route those calls correctly.

Additionally, the From headers of inbound calls from some PBXs does not conform to RFC 3966 because they are not prefixed with a plus sign. Microsoft Office Communicator cannot resolve these numbers to the correct user.

To assure interoperability with these PBXs, Office Communications Server 2007 R2 has a new Mediation Server setting for WMI called RemovePlusFromRequestURI. This setting can be set to TRUE or FALSE. The default value is FALSE.

  • If a PBX downstream from the Office Communications Server 2007 R2 Mediation server does not accept numbers prefixed with a plus sign, set the value of RemovePlusFromRequestURI to TRUE. This causes Mediation Server to remove the plus signs from the Request URIs of outgoing calls. It also causes the plus signs to be removed from the To and From URIs.
  • If the downstream PBX accepts numbers prefixed with plus signs, leave the value of RemovePlusFromRequestURI set to its default value of FALSE. This causes Office Communications Server 2007 Mediation Server to pass Request URIs, To URIs, and From URIs unchanged (that is, with plus signs).

Support for Private Numbering Plans

Office Communications Server 2007 R2 also introduces support for private numbering plans by normalizing From headers that are not in E.164 format. If the result of this normalization is not in E.164 format, Office Communications Server 2007 R2 inserts a P-Asserted-ID header with a phone-context value of enterprise to enable user lookup in Office Communicator 2007 R2. However, if the URI already contains a phone-context value of enterprise, Office Communications Server 2007 R2 does not normalize the From header.

 

Advertisements

08/10/2012 Posted by | OCS, Unified Communcation | , | Leave a comment

Enterprise Voice Deployment Requirements

In addition to deploying media gateways (which are not required for SIP trunking connections), you must also plan for the normalization of the phone numbers that are stored in Active Directory Domain Services (AD DS) and create dial plans for each location where your organization does business, as well as meet other requirements specific to the implementation method you chose for your organization.

Also, if your organization is to integrate Exchange Unified Messaging with Office Communications Server, you must meet additional technical requirements for that integration.

Prerequisites

For an optimum experience when deploying Enterprise Voice, make sure that your IT infrastructure, network, and systems meet the following prerequisites:

  • Microsoft Office Communications Server Standard Edition or Enterprise Edition is installed and operational on your network.
  • All Edge Servers and a reverse proxy are deployed and operational in your perimeter network.
  • Exchange Server 2007 SP1 is installed if you are integrating Exchange Unified Messaging with Office Communications Server.
  • One or more users have been created and enabled for Office Communications Server.
  • A primary phone number has been designated, normalized, and copied to the msRTCSIP-line attribute for each user who is to be enabled for Enterprise Voice. The administrator is responsible for ensuring that this number is unique.
  • Administrators deploying Enterprise Voice should be members of the RTCUniversalServerAdmins group.
  • Office Communicator and Live Meeting are successfully deployed.
  • Public key infrastructure (PKI) is deployed and configured, using either a Microsoft or a third-party certification authority (CA) infrastructure.
  • Each computer on which you install Mediation Server is:
  • Prepared for Active Directory Domain Services. For details about Active Directory Domain Services preparation procedures, see Office Communications Server 2007 R2 Active Directory Guide in the Deployment documentation.
  • Running one of the following operating systems:
    • The 64-bit edition of the Windows Server 2008 Standard operating system or the 64-bit edition of the Windows Server 2008 Enterprise operating system
    • The Windows Server 2003 R2 Standard x64 Edition operating system with Service Pack 2 (SP2) or the Windows Server 2003 R2 Enterprise x64 Edition operating system with SP2
    • The Windows Server 2003 Standard x64 Edition operating system with SP2 or the Windows Server 2003 Enterprise x64 Edition operating system with SP2
  • One or more media gateways are available for deployment. (Media gateways are not required with SIP trunking.)

Table 1. Enterprise Voice Technical Requirements Table

Implementation method Technical requirements
PBX coexistence IP-PBX that natively supports SIP and IP media in a format that is interoperable with Office Communications Server.

OR

A PBX combined with a media gateway that connects the PBX to the Office Communications Server infrastructure.

A/V Edge Server for media relay across network address translations (NATs) and firewalls.

Mediation Server configured with the IP address of the PBX and the fully qualified domain name (FQDN) of the A/V Edge Server.

Users enabled for Enterprise Voice and PBX integration.

Voice mail configured on PBX.

Stand-Alone Options  
Departmental IP-or TDM PBX.

Basic, basic hybrid, or advanced media gateway configured to connect departmental deployment with PBX.

Additional other gateways as required for PSTN connections.

A/V Edge Server for media relay across NATs and firewalls.

Mediation server configured with IP address of basic or basic hybrid media gateway (not required for advanced gateway).

Users enabled for Enterprise Voice.

Call forwarding independently configured separately on Office Communicator and PBX.

Exchange Unified Messaging deployed and configured to provide voice mail for Enterprise Voice users (PBX continues to supply voice mail for all other users).

Interface Cards for Mediation Server

To help ensure the physical as well as logical separation of your Enterprise Voice infrastructure from the media gateways, you should install Mediation Server on a computer that is equipped with two network interface cards (NICs). One card faces the gateway; the second card faces the Office Communications Server 2007 server that acts as the Mediation Servers internal next hop.

When you install Mediation Server, the Deployment Wizard detects the presence of the two network cards and writes their IP addresses to the Office Communications Server listening IP address list and the Gateway listening IP address list, both on the General tab of the Mediation Server properties dialog box.

The Office Communications Server listening IP address is the address on an advanced media gateway that listens for call traffic from Office Communications Server. Until advanced media gateways are available, this address corresponds to the network card that serves as the internal edge of the Mediation Server.

The Gateway listening IP address is the address on the Mediation Server that lists traffic from a basic media gateway or Basic Hybrid Media Gateway. For Office Communications Server 2007, this address corresponds to the network card that serves as the external edge of the Mediation Server.

Media Bandwidth Requirements

For basic media gateways, the bandwidth requirement between gateway and Mediation Server is 64 kilobits per second (Kbps) for each concurrent call. Multiplying this number by the number of ports for each gateway is a fair estimate of the required bandwidth on the gateway side of the Mediation Server. On the Office Communications Server side, the bandwidth requirement is considerably lower.

When configuring Mediation Server, you are advised to accept the default media port gateway range of 60,000 to 64,000. Reducing the port range greatly reduces server capacity and should be undertaken only for specific reasons by an administrator who is knowledgeable about media port requirements and scenarios. For this reason, altering the default port range is not recommended.

High-bandwidth traffic such as voice and video tends to stress poorly provisioned networks. Limiting media traffic to a known range of ports makes troubleshooting such problems easier.

Gateway Configuration Requirements

The settings that you must configure on your Basic Media Gateway are specified in the following list, but for information about how to configure these settings on a given gateway, refer to the manufacturer’s product documentation. Each gateway must be configured according to the vendor’s documentation. Depending on the vendor, there are potentially many attributes that must be set, but the attributes specific to Enterprise Voice are as follows:

  • The FQDN and IP address of the Mediation Server that is associated with the gateway.
  • The listening port (5060) that is used for TCP connections to the Mediation Server.
  • SIP Transport – specify either TLS (recommended) or TCP.
  • If the SIP transport for the link between the gateway and the Mediation Server is set to TLS, the gateway must be configured with a certificate for purposes of authentication during the mutual TLS (MTLS) handshake with the Mediation Server. The certificate on the gateway must be configured as follows:
  • The certificate may be directly signed by the trusted CA configured in the Mediation Server. Alternatively, a certificate chain may have to be traversed to verify the certificate provided by the gateway. The gateway must provide this chain as part of its TLS handshake with the Mediation Server.
  • The CN part of the subject field should be set to the FQDN of the gateway. If the FQDN in the CN part of the subject field does not match the expected and configured FQDN for the gateway, the certificate must also contain a subject alternate name (SAN) that lists the expected and configured FQDN for the gateway.
    The Mediation Server validates the certificate provided by the gateway by checking that the FQDN on the certificate exactly matches the gateway FQDN configured on the Mediation Server. If the FQDNs do not match, the session is terminated. Additional validation includes checking the signature and expiration date, and making sure that the certificate has not been revoked.
  • TLS link between media gateway and Mediation Server: 5060.
  • TLS link between Mediation Server and Office Communications Server pool: 5061.
  • If the SIP transport for the link between the gateway and the Mediation Server is set to TLS, separate ports must be opened for the TLS connection to the gateway and the TLS connection to the Office Communications Server pool. The port assignments should be configured as follows:
  • Each gateway must be configured so that the E.164 numbers routed by Enterprise Voice to the gateway are normalized to a locally dialable format.
  • Each gateway must also be configured to pass only E.164 numbers to the Mediation Server. For details about how to normalize source phone numbers to E.164, see each gateway vendor’s documentation.
  • Each gateway should be configured to convert the source number (the number presented as caller ID) to a normalized E.164 number. This ensures the caller ID can be matched to an Office Communicator contact, a Microsoft Office Outlook contact, or a member of the corporate directory, thereby enabling Office Communicator to provide additional information about the caller. This number will also appear in e-mail messages notifying the user of missed calls and voice mail, allowing the user to click the phone number in order to quickly return a call. If the number has been normalized by the gateway, no further processing is required. If for some reason the number cannot be normalized by the gateway, the normalization rules defined by the location profile will be applied when returning a call. It might be necessary to add normalization rules to a location profile to handle numbers that cannot be normalized by the gateway. For details about how to normalize source phone numbers to E.164, see each gateway vendor’s documentation.
  • Each gateway should also be configured to convert numbers in E.164 format into a format that will be accepted on the PSTN network. For example, when +1425xxxxxx is dialed, the gateway should strip the +1425 if the gateway is in Redmond, because these prefixes are not required for a local call.

 

Decisions to Make Before Deploying SIP Trunking

Among the many decisions to be made before deploying SIP trunking are:

  • Does a cost-benefit analysis justify the deployment of SIP trunking?
  • Who will be the SIP trunking service provider?
  • What additional hardware and software will be required?
  • What additional personnel and training will be required?
  • Will there be changes in licensing requirements?
  • Where will the SIP trunking endpoints be located?

Identifying Network or Infrastructure Requirements and Prerequisites for SIP Trunking

The principal task in deploying SIP trunking is configuring a virtual private network (VPN) to a SIP service provider. Many of the system requirements beyond the everyday requirements for the operation of Office Communications Server will be related to this task, and they will require you to work closely with the SIP trunking service provider.

 

08/10/2012 Posted by | OCS, Unified Communcation | | Leave a comment

How to: Apply a service pack or hotfix SQL Server 2008 to a failover cluster instance

Installing Service Pack SQL Server 2008 in failover cluster is very different than the SQL Server 2005 cluster failover.

With SQL Server 2005, when you start installing cluster service pack (or hotfix), it must be launched on the active node (node that hosts the instance). When installing the Setup will launch simultaneously  “remote silence” on all passive nodes. All nodes in the cluster containing the SQL Server instance are updated in the same time.

With SQL Server 2008, to reduce the downtime, we have revised the method of deployment. Now if you want to apply a service pack (or hotfix), you must install in first on the passive nodes. The passive nodes are updated before the active node.

Therefore, for your instance SQL Server 2008  in failover cluster, you must follow the scenario below for the application of Service Pack, Cumulative Update or Hotfix :

1.  Apply the hotfix on pasive node N2
2.  Reboot the passive node N2
3.  Failover on SQL resource : the passive node become the active node
4.  Apply the hotfix on the passive node N1
5.  Reboot the passive node N1

08/10/2012 Posted by | Sql Server | , | Leave a comment

Considerations when using Outlook 2003 with Exchange 2010

1.     Common Client Access Considerations for Outlook 2003 and Exchange 2010

There are several scenarios for consideration when deploying Exchange Server 2010 into an environment where Outlook 2003 is used. Most of these scenarios have been documented prior to the product release and some applied to previous versions. However, in a review of support cases, we have found that they have not been used prior to contacting Microsoft.

This document introduces some of the scenarios and the articles that will resolve these issues. If you are planning a deployment of Exchange Server 2010, understanding client configuration, and the requirements and capabilities of your organization are of importance to the user experience.  Primarily field office environments or environments where users are not joined to the domain, profile distribution, or the ability or inability to enforce policies or distribute the solutions will dictate how you address the issue.

2.      Encryption

This is a top support issue for Outlook 2003 access to Exchange 2010.

Exchange Server 2010 introduces additional “out of the box” security for Client communications to the Exchange Server – encryption between the Client and the Server is enabled, by Default. This is RC4 encryption – where the client negotiates the encryption level based on the client operating system’s capabilities – up to 128-bit encryption.  This is documented in the following topic in TechNet online:

Understanding RPC Client Access
http://technet.microsoft.com/en-us/library/ee332317.aspx

Prior to Outlook 2007, encryption was not enabled on the Client side, by default.   However, if profiles for Outlook 2007 exist where encryption is disabled, or if Outlook 2003 profiles created with default settings are used with Exchange Server 2010, the connection will fail when Outlook attempts to connect to an Exchange Server 2010 mailbox. One or more of the following common error messages will be displayed:

  • Cannot start Microsoft Office Outlook. Unable to open the Outlook window. The set of folders could not be opened.
  • Unable to open your default e-mail folders. The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance.
  • The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action.
  • Unable to open your default e-mail folders. The information store could not be opened.
  • Outlook could not log on. Check to make sure you are connected to the network and are using the proper server and mailbox name. The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action.

There are several methods to work around this issue, from immediate manual change by the administrator or the user, to deployment of administrative templates or new profiles.  Each of these scenarios is documented in the following article from the Microsoft Knowledge Base:

Outlook connection issues with Exchange 2010 mailboxes because of the RPC encryption requirement
http://support.microsoft.com/kb/2006508

3.      New Mail Notifications and UDP

Exchange 2010 no longer supports UDP for new mail notifications. However, Outlook 2003 relied primarily upon UDP notifications to display new messages and changes to folders. The result is that Outlook 2003 users will see delays in updates to folders and the Send/Receive process appears to take a long time.

The following article discusses the issue and two possible resolutions for the organization:

In Outlook 2003, e-mail messages take a long time to send and receive when you use an Exchange 2010 mailbox
http://support.microsoft.com/kb/2009942

4.     Address Book Service (Directory Access)

Directory access has changed in the Exchange Server 2010 world. The following TechNet topic introduces the changes and is currently being updated with more information.

Understanding the Address Book Service
http://technet.microsoft.com/en-us/library/ee332346.aspx

A future topic will cover this in more detail.

5.     Public Folders, Offline Address Book and Free/Busy

Outlook 2003 uses the Public Folders free/busy messages to determine availability in the Calendar and as the source for Offline Address Book synchronization. If Public Folders are not configured during Exchange Server 2010 setup, Offline Address Book and Free/Busy will not be available to Outlook 2003 users. These users will encounter connection errors.

If free/busy Public Folders folder is not replicated to Exchange Server 2010, users will encounter the following:

Users who use Outlook 2003 cannot publish their free/busy data in Exchange Server 2010 or in Exchange Server 2007
http://support.microsoft.com/kb/945602

If clients inside the organization or connected via VPN/RAS, and the organization uses a Proxy server, the Client Access Server should be listed in the “Bypass proxy server for local addresses” configuration.

Error message when Outlook synchronizes an offline address book with Exchange Server 2007 and Exchange Server 2010: “0x8004010F”
http://support.microsoft.com/kb/939765

Also, if there are missing address book list objects or missing or incorrect address lists, the following may occur:

An error occurs when you try to synchronize the offline address list on an Exchange Server server while you are using Outlook 2003: “0x8004010F”
http://support.microsoft.com/kb/905813

6.      Opening Additional Mailboxes

Delegate Access issues, opening other user’s folders or mailboxes are a common operation in the enterprise. Outlook 2003 users may encounter issues, if the environment is not properly prepared for their use:

Office Outlook 2003 does not connect to two or more additional mailboxes in a mixed Exchange Server 2007 and Exchange Server 2010 environment
http://support.microsoft.com/kb/978777

Anerror occurs when an Exchange server 2003 user tries to open more than one delegate mailboxes of Exchange Server 2010 in Outlook 2003
http://support.microsoft.com/kb/979690

7.      RPC over HTTP Connectivity

The following article discusses issues with Outlook 2003 connectivity when the RPC proxy server extensions do not load correctly. This article also applies to Exchange Server 2010 connections.

Error message when Outlook2003 users connect to an Exchange server by using RPC over HTTP: “Server Unavailable”
http://support.microsoft.com/kb/919092

8.      Unified Communications

Integration features with Office Communicator and functionality with Office Communications Server have been documented in the following documents:

The presence information for a Communications Server user may not appear, or may appear intermittently, in Outlook 2003 Service Pack 2 or in Outlook 2007
http://support.microsoft.com/kb/968099

*Communicator does not update the free/busy information as scheduled
http://support.microsoft.com/kb/941103

*Note: This functionality is not available to Outlook 2003/Exchange Server 2003 users, as the Availability Service functionality is required for both the client and the Exchange Server. The only method to obtain this functionality is to upgrade both the client and the server(s).

08/10/2012 Posted by | Exchange server | , | Leave a comment

HOW TO: Prevent annoying spam from your own domain

One of the more annoying types of spam is the one that seems to be coming from your own domain; or worse— from your own email address! Of course, users from your own domain don’t generally spam each other— unless you’re using one of the free web-based email services. And most of us don’t spam ourselves.

Obviously, this is coming from a spammer who has spoofed your email address, or that of someone else from your domain. Unfortunately, SMTP— the protocol that allows mail clients and servers to exchange email, allows headers to be spoofed easily.

In Exchange Server 2007, Accepted Domains tell Exchange which domains to accept email for. If a domain – e12labs.com in this example, exists as an Accepted Domain, there is no reason external senders should use that domain in the MAIL or FROM headers.

You may have remote POP3/IMAP4 users who use SMTP to send mail. However, such sessions should be authenticated, and preferably use a separate Receive Connector.

Thanks to the extensive Transport Permissions model in Exchange 2007, we can easily prevent such spam. Receive Connectors have the ms-exch-smtp-accept-authoritative-domain-sender permission which dictates whether an Accepted Domain can be used in the MAIL orFROM headers. External/internet hosts submit mail to your server without authentication, as anonymous senders. To prevent anonymous senders from sending mail using your domain(s), we need to remove the ms-exch-smtp-accept-authoritative-domain-senderpermission assigned to them.

Use the following command to remove the ms-exch-smtp-accept-authoritative-domain-sender permission from NT Authority\Anonymous Logon on internet-facing Receive Connector(s):

Get-ReceiveConnector “My Internet ReceiveConnector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission

Once this permission is removed, when anonymous senders try to submit mail using your Accepted Domain(s), here’s how the SMTP conversation goes:

220 E12Postcard.e12labs.com Microsoft ESMTP MAIL Service ready at Wed, 3 Sep 2008 06:22:43 -0700
helo
250 E12Postcard.e12labs.com Hello [172.31.0.170]
mail from:jadams@e12labs.com
550 5.7.1 Client does not have permissions to send as this sender

Exchange stopped spoofing of P1/envelope headers. Let’s continue the session and try to spoof the P2 headers (the ones in the DATA part of the message) — maybe that’ll work!

mail from:someone@someotherdomain.com
250 2.1.0 Sender OK
rcpt to:jadams@e12labs.com
250 2.1.5 Recipient OK
data
354 Start mail input; end with .
from:jadams@e12labs.com
subject: Header spoofing

This is how we spoof headers, spoof headers.

.
550 5.7.1 Client does not have permissions to send as this sender
quit
221 2.0.0 Service closing transmission channel

As you can see, removing the ms-exch-smtp-accept-authoritative-domain-senderpermission stops spoofing of your domains in both envelope (P1) and message (P2) headers.

When not to remove the permission?
Is there a scenario where one should not remove the ms-exch-smtp-accept-authoritative-domain-sender permission from NT Authority\Anonymous Logon? Yes, on Receive Connectors used by internal or trusted SMTP hosts (such as copiers/scanners and application servers) that submit mail without authentication.

08/10/2012 Posted by | Exchange server | , | Leave a comment

Recovering Public Folders After Accidental Deletion

Part 1: Recovery Process

Overview

This two-part blog series will outline some of the recovery options available to administrators in the event that one or more public folders are accidentally deleted from the environment. The first part will explain the options, while the second part will outline the architectural aspects of public folders that drive the options.

Introduction

In older versions of Exchange, mailbox and mailbox database recovery was a long, complicated process involving backups, recovery servers, and changes to Active Directory. Successive versions of the product have introduced more and more functionality around recovery (recovery storage groups/databases, database replication, etc.), and we’re now at the point where restoring a mailbox is a seemingly trivial operation, and restoring a mailbox database is almost unheard of. But mailboxes aren’t the only data stored on Mailbox servers in Exchange Server 2010, and the procedure for restoring public folders and public folder databases differs greatly from the mailbox procedure.

Review of Recovery Options

The first two recovery options are detailed either in TechNet or elsewhere on the Exchange team blog site, so I’ll simply list them here and then move on to the real purpose of this blog.  The recovery options for public folders and public folder databases in Exchange Server 2010 are as follows, from the easiest to the most complex:

  1. Recover deleted folders via Outlook (detailed in http://technet.microsoft.com/en-us/magazine/dd553036.aspx).Note: Exchange Server 2010 Service Pack 2 fixes an issue where users were unable to use Outlook to recover deleted public folders. This is another reason to upgrade your Exchange Server 2010 systems to SP2 at the earliest opportunity.
  2. Recover deleted folders via ExFolders (http://blogs.technet.com/b/exchange/archive/2009/12/04/3408943.aspx).
  3. Recover folders via public folder database restore.

The first option is the easiest and most obvious – if an end user accidentally deletes a folder, he or she should be able to undelete that folder using Outlook. Failing that, an administrator should be able to use ExFolders to recover that folder. But what if these options won’t work in your situation? What if the end user didn’t realize he or she deleted the folder, and a month has passed? Or what if your organization has changed the retention settings for deleted public folders, and essentially eliminated the dumpster?  How do you recover public folders in this case?

Recovery Options

At the heart of public folder recovery is a painful truth: you can’t delete a public folder from the organization and recover it by simply restoring an older version of a public folder database. If you restore a public folder database from backup and place it back into production, you’ll see the public folders only until the server receives replication messages. Because the public folder hierarchy – the list of all folders in the environment – no longer includes the folders which were deleted, the target server has copies of folders which, from Exchange’s perspective, don’t exist. As soon as that public folder database receives a hierarchy update, it will see that those public folders aren’t present in the hierarchy, and the store will delete the public folder again. Since you can’t edit the hierarchy via the Public Folder Management Console (or even via adsiedit.msc), you can’t manually add that public folder back in. So, given this limitation, how do we recover that public folder?

Consider the following points:

  • If you don’t replicate every folder to every database, you would need to delete all current databases and then recover from backup any database that contains unique content.  This only works if you have recent backups, of course, and would also require that you export any content generated since that backup, since you’re going to delete all of the existing databases. The deletion is necessary because if a restored public folder store receives hierarchy replication from one of the existing public folder stores, the whole exercise is for naught.
  • If you do replicate all folders to all stores in the environment, you can delete all stores and just restore one database, then replicate the content from that database out to the other servers. Again, this depends on all databases having duplicate content, and you must delete all existing databases before restoring the one from backup.
  • You can restore a backup of the public folder database to an isolated Exchange environment, connect to the public folder database with Outlook, export all content to a series of PSTs, create new folders in the production environment with the same names as the deleted folders, and then import all of the content. This is obviously a somewhat manual process, and most administrators aren’t going to want to do this.

Recommended Recovery Procedure

Thankfully there is a much easier process which can be performed in-place and with a minimum of fuss.

  1. Select one of the existing public folder servers in the environment. [Using an existing server simplifies the process a bit.] You will isolate this system from its replication partners, so choose a system that doesn’t serve as the source for a lot of content which needs to be replicated.
  2. Using Registry Editor, set the value of the Replication registry key (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\<servername>\Public- <GUID of Public Store>) to 0(zero).Note: You may need to create this DWORD key if it doesn’t already exist. Further information on the Replication registry key is available in the article, “Replication does not occur for one Exchange server in the organization” (http://support.microsoft.com/kb/812294). This registry key also applies to Exchange Server 2007 and 2010.
  3. Restore the public folder database in place using your normal restoration procedure.
  4. Using an Outlook client, log onto a mailbox which uses the restored public folder database as its default public folder store (this is necessary in order to see the restored folders). If you don’t have a mailbox database which uses that public folder database as its default, either create a new mailbox database (recommended) or change an existing mailbox database to use the newly-restored public folder database.
  5. If necessary, click the Folders icon at bottom left of the Navigation screen, and then expand the public folders node.
  6. Copy each of the folders you wish to restore to another location within the public folder hierarchy. If you’re restoring an entire hierarchy, you can simply Ctrl-click and drag the root folder to make new copies of all subfolders. Although the new folders will have similar names to the originals, the underlying folder IDs (FIDs) are different.
  7. Once you’ve created copies of all of the folders, verify that the replica lists include all desired targets (and reconfigure as appropriate).
  8. At this point, it’s now safe to reintroduce that server into the production environment. To do so, dismount the public folder database, delete the Replication registry key (or set it to 1), and then remount the database.
  9. As soon as hierarchy is replicated to the server, the original folders will once again disappear, but the copies of the folders will be replicated to all replication partners.

You may need to add mail-enabled public folders back into distribution groups, as their SMTP addresses will likely be different from those on the original folders. End users will also need to recreate public folder favorites in Outlook.

Summary

Recovering from accidental public folder deletion can be difficult, especially if you don’t take hierarchy replication into account. By restoring into an isolated environment, and then cloning the folders to be restored, you can work around this limitation and restore the missing content. In the next blog entry, I’ll explain the underlying architecture of public folders (including replication, change numbers, and the replication state table) to show why these steps are so necessary.

———————————————————————————————————————————————————————————————————————————————————————————-

Part 2: Public Folder Architecture

 

Introduction

In this second part, I’m going to describe some of the inner workings of public folders themselves.  Each organization maintains a list of all public folders in the environment, as well as the locations of all replicas.  This list is called the hierarchy, and it’s common to all public folder stores in the environment.  The hierarchy lists all public folders in the environment as well as which servers host replicas of each folder.  Each public folder store has a copy of the hierarchy, and uses it to provide referrals to end users for public folder replicas on other servers (among other things).  Each public folder store also maintains a table, called the replication state table, which keeps track of the status of each folder.  This table is a critical yet little understood feature of public folders, and it has a huge impact on recovery.

Overview

As I said above, each public folder store maintains a replication state table, but unlike the hierarchy, it’s unique to each store.  A public folder store maintains information about the public folders for which it has a replica, not just for itself but for all servers with that replica.  It does this so that it knows which other stores have more up-to-date public folder content, or which ones might have items required for backfill replication (catching up on old or missing items).

Imagine the following scenario:  we have three servers, each hosting a public folder database – PFS1, PFS2, and PFS3.  We have a folder – Folder1 – which is replicated to each database.  If I could peer into the replication state table for PFDB1, I would see an entry for Folder1, and that entry would contain information about Folder1’s status not on for PFS1, but also for PFS2 and PFS3.  What kind of information does this table actually contain?  To answer that, we need to dig yet further into public folder structure, and talk about CNs.

Change Numbers

CNs – or, to give their full name, change numbers – are numbers assigned to each modification made to content in a public folder.  Think of them as per-folder odometers – they increment each time a change is made to a folder, and only increase, never decrease. Each public folder assigns CNs to the changes made on a given replica, and that information is transmitted to other replicas.  These other replicas use this information to see if they’ve already received a particular change.  For example, if I make a change to Folder1 on PFS1, that database might assign change number 211 to that modification.  When the public folder database replicates that change to other databases, it records and transmits that change as FID1-123:PFS1:211.  [Folder1 is represented within the public folder database, and by extension in the replication traffic, by a folder ID (FID). This becomes very important later.] PFS2 receives the replication message and checks to see if it has already received CN 211 from PFS1.  If it hasn’t, it applies the change and updates its own entry in the replication state table to reflect the fact that it has now received change 211 for Folder1 (FID1-123) from PFS1.  If PFS3 later replicates the same change (FID1-123:PFS1:211) to PFS2, PFS2 will check its list, see that it has indeed already received that change, and discard that particular replication message.

Here’s a sample hierarchy replication message. Notice the CN min, CN max, and FID entries in the description field.

Event Type: Information
Event Source: MSExchangeIS Public Store
Event Category: Replication Outgoing Messages
Event ID: 3018
Description:
An outgoing replication message was issued.
Type: 0x2
Message ID: <23599A0EB070AA92F03E31C546C9C8FFA4F7@contoso.com>
Database “PFDB”
CN min: 1-11D3, CN max: 1-11D4
RFIs: 1
1) FID: 1-38BF, PFID: 1-1, Offset: 28
IPM_SUBTREE\TestPF

At any given time, each public folder store knows exactly what content it has, and has a general idea of what content the other public folder stores have.  This is an important point – public folder databases are aware of their environment surroundings.  It’s this awareness that has implications for recovery.

The Replication State Table

Here’s a quick visualization of how a public folder change is propagated from one server to another. This table simulates the replication state table which is internal to every server. There are four columns – the first represents the replication details (the CNsets), and the next three represent the same folder on each of the three servers. In essence, this table shows you what each server knows about other server’s knowledge of this particular folder. Please note that this is a simplified version of the replication state table – it’s actually quite a bit more complicated than this, but this is all the detail 99.99% of engineers will ever need.

In this example, Folder1 has been replicated to three systems – PFS1, PFS2, and PFS3 – and public folder replication is fully up-to-date. The servers know what they’ve sent to their replication partners, and what’s been replicated back to them. Since end users could conceivably make updates on any of the servers, they each have their own CN sets for the same folder.

Details From Folder1 on PFS1 Folder1 on PFS2 Folder1 on PFS3
PFS1 Last sent CN PFS1:10 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS2 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

Last sent CN PFS2:20 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS3 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

Last sent CN PFS3:30

An end user connected to PFS1 makes a change, which PFS1 assigned change number 11. The replication state table on PFS1 is updated to reflect this new CN.

Details From Folder1 on PFS1 Folder1 on PFS2 Folder1 on PFS3
PFS1 Last sent CN PFS1:11 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS2 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

Last sent CN PFS2:20 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS3 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

Last sent CN PFS3:30

PFS1 packages this change (which we assume is the only one made to Folder1) and sends it to PFS2 and PFS3, which update their own replication state tables.

Details From Folder1 on PFS1 Folder1 on PFS2 Folder1 on PFS3
PFS1 Last sent CN PFS1:11 FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS2 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

Last sent CN PFS2:20 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS3 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

Last sent CN PFS3:30

Both PFS2 and PFS3 apply the changes, and since those two systems received the change from PFS1, they also update their “knowledge” of PFS1. Notice that PFS1 does not update its entries for PFS2 and PFS3 – while it has sent the content to them, it hasn’t received confirmation that they’ve applied that change. [Because public folder replication messages are delivered via Hub Transport, public folder stores don’t directly interact and so never assume that the updates were delivered and applied.]

Continuing with our example, an end user makes a change to Folder1 on PFS3:

Details From Folder1 on PFS1 Folder1 on PFS2 Folder1 on PFS3
PFS1 Last sent CN PFS1:11 FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS2 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

Last sent CN PFS2:20 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS3 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

Last sent CN PFS3:31

That change is now replicated to PFS1 and PFS2:

Details From Folder1 on PFS1 Folder1 on PFS2 Folder1 on PFS3
PFS1 Last sent CN PFS1:11 FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS2 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

Last sent CN PFS2:20 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS3 FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-31

FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-31

Last sent CN PFS3:31

Note that when PFS3 sent out its replication message, it included not only its own update, but also the fact that it had received update 11 from PFS1.

Again, while every server has the most up-to-date content for Folder1, they don’t necessarily know that every replica is up-to-date. [PFS1, for example, “thinks” that PFS2 is out of date, while PFS3 “thinks” that both PFS1 and PFS2 are out of date.] It’s important to note that this isn’t a problem – by only encapsulating status messages in outgoing replication, Exchange avoids saturating the network with constant messages from various servers confirming the receipt of recent replication messages.

Backfill Replication

However, from time to time, a server loses its connection to its replication partners, either through network failure, service failure, or other causes. When it does, its replication state table no longer receives updates to the CNs held by its partners for their replicas. In other words, its replication state table is outdated. When that server reconnects with its partners, and receives a new message, it may find that the CN on that new message is much higher than what it expected. Using the previous example, imagine that PFS3 is isolated from PFS1 and PFS2 due to a server failure, and does not receive updates to Folder1 from the other servers for several hours. The resulting table might look like this:

Details From Folder1 on PFS1 Folder1 on PFS2 Folder1 on PFS3 (OFFLINE)
PFS1 Last sent CN PFS1:16 FID1-123:PFS1:1-16

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS2 FID1-123:PFS1:1-16

FID1-123:PFS2:1-28

FID1-123:PFS3:1-30

Last sent CN PFS2:28 FID1-123:PFS1:1-10

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS3 FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-31

FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-31

Last sent CN PFS3:31

Notice that PFS1 is aware that the most recent replication message from PFS2, for change number 28, also included information about PFS2’s knowledge of PFS1 (namely, that PFS2 receives PFS1’s update numbers 12 to 16). PFS3 has not received any of these recent updates.

However, when PFS3 is brought back online, and receives a new replication message, it suddenly learns of the missing messages. This triggers a backfill request– a request from PFS3 to the source server for the missing content.

Details From Folder1 on PFS1 Folder1 on PFS2 Folder1 on PFS3
PFS1 Last sent CN PFS1:17 FID1-123:PFS1:1-17

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

FID1-123:PFS1:1-11, 17

FID1-123:PFS2:1-20

FID1-123:PFS3:1-30

PFS2 FID1-123:PFS1:1-16

FID1-123:PFS2:1-28

FID1-123:PFS3:1-30

Last sent CN PFS2:28 FID1-123:PFS1:1-16

FID1-123:PFS2:1-28

FID1-123:PFS3:1-30

PFS3 FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-31

FID1-123:PFS1:1-11

FID1-123:PFS2:1-20

FID1-123:PFS3:1-31

Last sent CN PFS3:31

Backfill Request PFS1:12-16

Backfill Request PFS2:21-28

Notice that PFS3 is missing updates 12 through 16 for PFS1, and 21 through 28 for PFS2. PFS3 will request the missing content from any server that it believes has that content, which in this case would mean either PFS1 or PFS2. How does PFS3 know that both servers have the content? Because the replication message from PFS1, which included change number 17, included the information about the CN sets for PFS1, PFS2, and PFS3.

Strictly speaking, Exchange doesn’t issue these backfill requests right away – it waits a few hours (six or more, depending on the situation) before sending them out, just in case one of its replication partners happens to send that missing content. If a specific update hasn’t been received after the backfill timeout is reached, Exchange then generates that backfill request and sends it to the replication partners. This process is detailed in the “Backfill Requests and Backfill Messages” section of the TechNet page on “Understanding Public Folder Replication” at http://technet.microsoft.com/en-us/library/bb629523.aspx#Backfill.

Removing or Deleting Replicas

When you remove a public folder replica, the owning public folder database contacts all other database to find out if they have all of the content that’s contained within the replica that’s about to be removed.  It does so by sending out a status message that contains the CNs for its replica of the folder. For example, if I were to remove the replica of Folder1 from PFS3, it would send a message to PFS1 and PFS2 confirming that between the two of them, they have every update from PFS3 from 1 to 31. [This is an important point: the content doesn’t need to be on one server. As long as the content exists somewhere in the organization, the replica can be removed.] If PFS3 had any unique content that neither PFS1 nor PFS2 had, it would replicate those items to its replication partners. Once it has confirmed that it no longer has any unique content, the public folder store removes that replica.

However, when you delete a public folder outright (as in, remove all replicas), there’s no need to preserve content, so it’s deleted from every public folder store.  This is why it’s vital that public folder administrators understand the difference between removing a replica (with Set-PublicFolder -Replicas) and deleting a public folder (with Remove-PublicFolder).

These changes to replica lists and outright deletions are transmitted just like any other public folder change – as hierarchy replication messages, complete with their own CNs.  If I remove the replica of Folder1 from PFS1, that change will go to PFS2 and PFS3 so that they know that they no longer need to replicate new content for Folder1 to PFS1.  Likewise, if I delete Folder1, it will be deleted from all of the databases and removed from the hierarchy as well.  The replication state table keeps track of changes to hierarchy too, and so knows which folders exist in the organization and which don’t. It is this tracking mechanism that prevents us from simply restoring a public folder database and reintroducing the deleted folders into the environment.

Recovery of Deleted Public Folders

In part one of this blog, I outlined a process for safely and successfully restoring public folders which were accidentally deleted from the environment. Step six of the procedure reads, in part, “Copy each of the folders you wish to restore. [Although the new folders will have similar names to the originals, the underlying folder IDs (FIDs) are different.]” I’ve added italics to highlight the key point – when you copy (clone) public folders, you’re really creating new folders. They may bear the same name as the originals, but the folder IDs are different. So although my cloned copy of Folder1 may look like the original Folder1, and contain the same items as Folder1, none of the replication messages for the original Folder1 will apply to it, because it’ll have a completely different FID. This new folder is added to the hierarchy, and because end users see the name, not the FID, they’ll simply use it as they would the original folder.

Troubleshooting Replication

If you’re looking for troubleshooting information, look no further than Bill Long’s excellent four-part blog series on public folders:

Summary

Public folders use their own replication mechanism, where changes are tracked in an internal, non-editable table and communicated to replication partners alongside the actual content changes. The public folder hierarchy follows the same principles, and so changes made to the hierarchy are replicated to all public folder databases in the environment. Understanding the replication mechanism helps an administrator understand not only disaster recovery, but troubleshooting as well.

07/10/2012 Posted by | Exchange server, Public Folders, Recovering/Restore | , , | Leave a comment

Rebuild MSDB Database

If you accidentally delete the transaction log file of msdb database on a newly installed SQL Server 2008 R2 instance do the following steps

I searched Books Online and found this article about Rebuilding System Databases, which helps in rebuild the msdb database.

Steps to Follows

  1. Stop all the SQL Server services & start the command prompt with elevated administrative privilege & execute the following command:
    NET START MSSQLSERVER /T3608
  2. Once you start the SQL Server with trace flag 3608, you will be able to detach the msdb database. To do that, execute the following command in SQLCMD mode:
    SQLCMD -E -S DBS03 -dmaster -Q"EXEC sp_detach_db msdb"
  3. Rename the msdb data file, and execute the instmsdb.sql file from the install folder, as shown below:
    SQLCMD -E -S DBS03 -i"E:\SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Install\instmsdb.sql" -o"E:\instmsdb.out"
  4. Review the instmsdb.out for any errors and re-apply the service packs.
  5. Stop the SQL Server.
  6. Start the SQL Server normally

StepstoFollow

Since I was able to connect to the instance without any error, I stopped the SQL Server instance and copy all the system databases files. Later I restarted the SQL Server Agent and the instance was online.

Hope, this may help someone, Happy Learning Smile

06/19/2012 Posted by | SQL Scripting, Sql Server, T-SQL | , , | Leave a comment

Exchange Server and Update Rollups Build Numbers

Exchange Server Release dates

Product name Build number Date
 Microsoft Exchange Server 2003  6.5.6944  6/30/2003
 Microsoft Exchange Server 2003 SP1  6.5.7226  5/25/2004
 Microsoft Exchange Server 2003 SP2  6.5.7638  10/19/2005
 Microsoft Exchange Server 2007  8.0.685.24  12/9/2006
 Microsoft Exchange Server 2007  8.0.685.25  12/9/2006
 Microsoft Exchange Server 2007 SP1  8.1.240.6  11/29/2007
 Microsoft Exchange Server 2007 SP2  8.2.176.2  8/24/2009
 Microsoft Exchange Server 2007 SP3  8.3.083.6  6/20/2010
 Microsoft Exchange Server 2010  14.0.639.21  11/9/2009
 Microsoft Exchange Server 2010 SP1  14.1.218.15  8/24/2010
 Microsoft Exchange Server 2010 SP2  14.2.247.5  12/4/2011

Exchange Server 2007 Service Pack 1

Product name Build number Date KB
 Microsoft Exchange Server Exchange 2007 SP1  8.1.240.6  11/29/2007
 Update Rollup 1 for Exchange Server 2007 Service Pack 1  8.1.263.1  2/28/2008  KB945684
 Update Rollup 2 for Exchange Server 2007 Service Pack 1  8.1.278.2  5/8/2008  KB948016
 Update Rollup 3 for Exchange Server 2007 Service Pack 1  8.1.291.2  7/8/2008  KB949870
 Update Rollup 4 for Exchange Server 2007 Service Pack 1  8.1.311.3  10/7/2008  KB952580
 Update Rollup 5 for Exchange Server 2007 Service Pack 1  8.1.336.1  11/20/2008  KB953467
 Update Rollup 6 for Exchange Server 2007 Service Pack 1  8.1.340.1  2/10/2009  KB959241
 Update Rollup 7 for Exchange Server 2007 Service Pack 1  8.1.359.2  3/18/2009  KB960384
 Update Rollup 8 for Exchange Server 2007 Service Pack 1  8.1.375.2  5/19/2009  KB968012
 Update Rollup 9 for Exchange Server 2007 Service Pack 1  8.1.393.1  7/17/2009  KB970162
 Update Rollup 10 for Exchange Server 2007 Service Pack 1  8.1.436.0  4/9/2010  KB981407


Exchange Server 2007 Service Pack 2

Product name Build number Date KB
 Microsoft Exchange Server 2007 SP2  8.2.176.2  8/24/2009
 Update Rollup 1 for Exchange Server 2007 Service Pack 2  8.2.217.3  11/19/2009  KB971534
 Update Rollup 2 for Exchange Server 2007 Service Pack 2  8.2.234.1  1/22/2010  KB972076
 Update Rollup 3 for Exchange Server 2007 Service Pack 2  8.2.247.2  3/17/2010  KB979784
 Update Rollup 4 for Exchange Server 2007 Service Pack 2  8.2.254.0  4/9/2010  KB981383
 Update Rollup 5 for Exchange Server 2007 Service Pack 2  8.2.305.3  12/7/2010  KB2407132

 

Exchange Server 2007 Service Pack 3

Product name Build number Date KB
 Microsoft Exchange Server 2007 SP3  8.3.083.6  6/20/2010
 Update Rollup 1 for Exchange Server 2007 Service Pack 3  8.3.106.2  9/9/2010  KB2279665
 Update Rollup 2 for Exchange Server 2007 Service Pack 3  8.3.137.3  12/10/2010  KB2407025
 Update Rollup 3 for Exchange Server 2007 Service Pack 3  8.3.159.0  3/2/2011  KB2492691
 Update Rollup 3-v2 for Exchange Server 2007 Service Pack 3  8.3.159.2  3/30/2011  KB2530488
 Update Rollup 4 for Exchange Server 2007 Service Pack 3  8.3.192.1  7/7/2011  KB2509911
 Update Rollup 5 for Exchange Server 2007 Service Pack 3  8.3.213.1  9/21/2011  KB2602324
 Update Rollup 6 for Exchange Server 2007 Service Pack 3  8.3.245.2  1/25/2012  KB2608656
 Update Rollup 7 for Exchange Server 2007 Service Pack 3  8.3.264.0  4/16/2012  KB2655203


Exchange Server 2010

Product name Build number Date KB
 Microsoft Exchange Server 2010 RTM  14.0.639.21  11/9/2009
 Update Rollup 1 for Exchange Server 2010  14.0.682.1  12/9/2009  KB976573
 Update Rollup 2 for Exchange Server 2010  14.0.689.0  3/4/2010  KB979611
 Update Rollup 3 for Exchange Server 2010  14.0.694.0  4/9/2010  KB981401
 Update Rollup 4 for Exchange Server 2010  14.0.702.1  6/17/2010  KB982639
 Update Rollup 5 for Exchange Server 2010  14.0.726.0  12/13/2010  KB2407113


Exchange Server 2010 Service Pack 1

Product name Build number Date KB
 Microsoft Exchange Server 2010 SP1  14.1.218.15  8/24/2010
 Update Rollup 1 for Exchange Server 2010 SP1  14.1.255.2  10/4/2010  KB2407028
 Update Rollup 2 for Exchange Server 2010 SP1  14.1.270.1  12/9/2010  KB2425179
 Update Rollup 3 for Exchange Server 2010 SP1  14.1.289.3  3/7/2011  KB2492690
 Update Rollup 3-v3 for Exchange Server 2010 SP1  14.1.289.7  4/1/2011  KB2529939
 Update Rollup 4 for Exchange Server 2010 SP1  14.1.323.1  6/22/2011  KB2509910
 Update Rollup 4-v2 for Exchange Server 2010 SP1  14.1.323.6  7/27/2011  KB2579150
 Update Rollup 5 for Exchange Server 2010 SP1  14.1.339.1  8/23/2011  KB2582113
 Update Rollup 6 for Exchange Server 2010 SP1  14.1.355.2  10/27/2011  KB2608646

Exchange Server 2010 Service Pack 2

Product name Build number Date KB
 Microsoft Exchange Server 2010 SP2  14.2.247.5  12/4/2011
 Update Rollup 1 for Exchange Server 2010 SP2  14.2.283.3  2/13/2012  KB2645995
 Update Rollup 2 for Exchange Server 2010 SP2  14.2.298.4  4/16/2012  KB2661854
 Update Rollup 3 for Exchange Server 2010 SP2  14.2.309.2  5/29/2012  KB2685289

06/13/2012 Posted by | Exchange server | , | Leave a comment

Tracking Login Password Changes in SQL Server

Problem

By default, SQL Server does not keep track of login password changes. When the question initially came up with a user, I thought that perhaps it might be in the default trace or in the system_health extended event session. No such luck. So I was in search of an alternate way to keep track of these events, if not retroactively, at least going forward.

Solution

In a short time you can be up and running with collecting password change information using three different methods: server-side trace, event notifications, and SQL Server audit. Below I will provide an example using each technology. Note that all three examples are able to track password changes using ALTER LOGIN, the system procedure sp_password (deprecated since SQL Server 2005), or the Management Studio Login properties dialog.


Server-Side Trace

Trace includes an event called “Audit Login Change Password Event” – which is much more reliable than capturing all batches and filtering on ‘%sp_password%’ and ‘%ALTER%LOGIN%PASSWORD%’. The EventID is 107, so you can set up a very simple trace with the following code (make sure to set a proper path to the desired trace file):

DECLARE @TraceID INT, @MaxFileSize BIGINT;
SET @MaxFileSize = 5;

EXEC sp_trace_create 
    @TraceID OUTPUT, 
    2, 
    N'C:\Traces\PasswordChangeTrace', -- make sure to change this!
    @MaxFileSize,
    10; 

EXEC sp_trace_setevent @TraceID,107, 1,  1;
EXEC sp_trace_setevent @TraceID,107, 11, 1;
EXEC sp_trace_setevent @TraceID,107, 8,  1;
EXEC sp_trace_setevent @TraceID,107, 12, 1;
EXEC sp_trace_setevent @TraceID,107, 14, 1;
EXEC sp_trace_setevent @TraceID,107, 40, 1;
EXEC sp_trace_setevent @TraceID,107, 42, 1;

EXEC sp_trace_setstatus @TraceID, 1;

SELECT @TraceID;

Make note of the TraceID in the output. Once this has been running, you can use that TraceID to review the events that have been captured using the following query:

DECLARE @path NVARCHAR(255);

SELECT @path = [path]
FROM  sys.traces
WHERE id = <traceID from above>;

SELECT 
  LoginName  = TargetLoginName, 
  EventCount = COUNT(*), 
  FirstEvent = MIN(StartTime), 
  LastEvent  = MAX(StartTime)
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE EventClass = 107 -- in case you've added other events
GROUP BY TargetLoginName;

Since the above trace definition specifies a max of 10 x 5MB files, eventually an event that happens today will no longer be available through the above query. So as an added exercise you may consider periodically taking a snapshot of this data into a permanent table, and running your queries from there.


Event Notifications

An alternative to trace is to set up a targeted Event Notification. These are lightweight, asynchronous messages sent via Service Broker that can be used to perform various actions in response to a specific event. One such event is AUDIT_LOGIN_CHANGE_PASSWORD_EVENT. In a lot of cases people use these to send an e-mail or start a job, but in this case we’re just going to log to a table. We can create the following table in msdb:

USE [msdb];
GO

CREATE TABLE dbo.PasswordChangeLog
(
    LoginName  SYSNAME,
    EventTime  DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

We will then need to set up a queue and a notification to handle our events:

CREATE QUEUE PasswordChangeQueue;
GO

CREATE SERVICE PasswordChangeService ON QUEUE PasswordChangeQueue
  ([http://schemas.microsoft.com/SQL/Notifications/PostEventNotification]);
GO

CREATE EVENT NOTIFICATION PasswordChangeNotification
    ON SERVER WITH FAN_IN
    FOR AUDIT_LOGIN_CHANGE_PASSWORD_EVENT
    TO SERVICE 'PasswordChangeService', 'current database';
GO

And then the following procedure can be used to log events to our table:

CREATE PROCEDURE dbo.LogPasswordChange
WITH EXECUTE AS OWNER
AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @message_body XML;

    WHILE (1 = 1)
    BEGIN
       WAITFOR 
       ( 
         RECEIVE TOP(1) @message_body = message_body
         FROM dbo.PasswordChangeQueue
       ), TIMEOUT 1000;

       IF (@@ROWCOUNT = 1)
       BEGIN
        INSERT dbo.PasswordChangeLog(LoginName) 
          SELECT @message_body.value('(/EVENT_INSTANCE/LoginName)[1]', 'sysname');
       END
    END
END
GO

Finally, we can change the queue to call this stored procedure in response to the event:

ALTER QUEUE PasswordChangeQueue
WITH ACTIVATION
(
   STATUS = ON,
   PROCEDURE_NAME = dbo.LogPasswordChange,
   MAX_QUEUE_READERS = 1,
   EXECUTE AS OWNER
);
GO

Now change the password for a few logins, and you should see results from the following query:

SELECT 
  LoginName, 
  EventCount = COUNT(*), 
  FirstEvent = MIN(EventTime), 
  LastEvent  = MAX(EventTime)
FROM dbo.PasswordChangeLog
GROUP BY LoginName;

Server Audit

The final option I’ll present here is creating a Server Audit Specification. You may already be using Server Audit, and if so, handling password change auditing using this technology might make more sense than using either of the above two methods. (However note that Server Audit requires Enterprise Edition of SQL Server 2008 or SQL Server 2008 R2 – in SQL Server 2012, this feature has been made available in all editions.)

One of the options for a Server Audit Specification is LOGIN_CHANGE_PASSWORD_GROUP. We can set up a file-based audit to capture these events with the following code (note that this needs to be performed in master and you should update the file path appropriately – you probably don’t want to rely on C:\ for this):

USE [master];
GO

CREATE SERVER AUDIT ChangePasswordAudit
  TO FILE (FILEPATH = 'C:\Audits\', MAXSIZE = 5MB, MAX_ROLLOVER_FILES = 10)
  WITH (ON_FAILURE = CONTINUE); -- important unless you want your server to halt on failure

ALTER SERVER AUDIT ChangePasswordAudit
  WITH (STATE = ON);

CREATE SERVER AUDIT SPECIFICATION ChangePasswordAuditSpecification
  FOR SERVER AUDIT ChangePasswordAudit
  ADD (LOGIN_CHANGE_PASSWORD_GROUP)
  WITH (STATE = ON);
GO

Once this is running, you can change a few passwords and then retrieve data from the audit using the following query:

DECLARE @folder VARCHAR(255);

SELECT @folder = log_file_path + '*' 
  FROM sys.server_file_audits 
  WHERE name = 'ChangePasswordAudit';

SELECT 
  LoginName  = target_server_principal_name, 
  EventCount = COUNT(*),
  FirstEvent = MIN(event_time), 
  LastEvent  = MAX(event_time)
FROM sys.fn_get_audit_file(@folder, DEFAULT, DEFAULT)
WHERE action_id IN ('PWR', 'PWC') -- PWR = ALTER LOGIN / SSMS, PWC = sp_password
GROUP BY target_server_principal_name;

As with the trace above, this file-based audit is limited to 10 x 5MB files. So you may want to change those options to have the audit data hang around longer, or you may consider occasionally storing the result of this query in a permanent table.

One important thing to note about Server Audit is that it records the event time in UTC, so you might notice that the timestamps are off depending on your time zone. Therefore you may need to look into adding a helper function that will convert any UTC date to your time zone. Since this can get complicated with Daylight Saving Time, I’ve often found it easier to just set up all of our servers to do everything in UTC. 🙂


Conclusion

As you can see, there are a variety of ways to set up tracking for password changes, and each method is relatively straightforward to implement. While it is still impossible to obtain this information from the past, once you have implemented one of the above solutions, you will be able to look back on this information over time.

 

06/13/2012 Posted by | SQL Scripting, Sql Server, T-SQL | , | Leave a comment

Use PowerShell to gather SQL Server database physical file sizes

Problem

I am hired as an DBA at a customer and one of the SQL servers has a database that grows very rapidly (1 GB per week). I needed an easy way to monitor the growth of this database. I also needed an easy way to monitor all my servers for growth trending.

Solution

I know there are tools that will monitor database file size, but I wanted something easy and something I could use to gather and retain historical data. It also had to be free. After a little research I decided to try using PowerShell. I did some searching on the internet and found some sample scripts for connecting to servers, getting data from those servers and then writing the data to an Excel spreadsheet.

Prepare the environment

Before we start let me say that I am not a PowerShell guru, so some of the terminology I use may not be exact. The first thing you will need to do is start PowerShell. In Windows 7 click the Start button and type PowerShell in the Search field. When I do this on my system I am presented with a couple choices. The first two items in the list will start PowerShell, Windows PowerShell ISE is a GUI interface and Windows PowerShell is the command line interface. I like to use Windows PowerShell ISE.

Program Selection

The next thing you will need to do to use PowerShell on your system is to change the execution policy. By default the execution policy is set to Restricted, this means that no scripts will run, not any at all. To check what the current execution policy is set to, open PowerShell and enter the command Get-ExecutionPolicy. I have set my execution policy to RemoteSigned, this allows scripts I have written to run and to run scripts from the internet only if those scripts have been signed by a trusted publisher. To set the execution policy enter the command Set-ExecutionPolicy RemoteSigned. Note: there are other options for execution policy, check the documentation for the appropriate policy. Now that I have the execution policy set I am ready to go.

What I wanted to accomplish was to look at all my SQL servers and get the actual data file and log file size in megabytes. The script shown below reads a .txt file that lists all my SQL servers and gets the file name, file path, file size, and used size for both data file (.mdf) and log file (.ldf) for each database on each server in the .txt file. The data is then written to a spreadsheet on my local machine.

#Create a new Excel object using COM 
$Excel = New-Object -ComObject Excel.Application
$Excel.visible = $True 
$Excel = $Excel.Workbooks.Add()
$Sheet = $Excel.Worksheets.Item(1)
$intRow = 1
 ForEach ($instance in Get-Content "C:\Users\dkelly\Documents\PowershellScripts\sqlservers.txt")
    {
    [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO') | out-null
    $s = New-Object ('Microsoft.SqlServer.Management.Smo.Server') $instance
    $dbs=$s.Databases

     $intRow++
     #Create column headers
     $Sheet.Cells.Item($intRow,1) = "Server: $s"
     $Sheet.Cells.Item($intRow,1).Font.Size = 12
     $Sheet.Cells.Item($intRow,1).Font.Bold = $True

     $intRow++
     $Sheet.Cells.Item($intRow,2) = "Database"
     $Sheet.Cells.Item($intRow,2).Font.Bold = $True
     $Sheet.Cells.Item($intRow,3) = "Data Name"
     $Sheet.Cells.Item($intRow,3).Font.Bold = $True
     $Sheet.Cells.Item($intRow,4) = "Data File"
     $Sheet.Cells.Item($intRow,4).Font.Bold = $True
     $sheet.Cells.Item($intRow,5) = "Data Size (MB)"
     $Sheet.Cells.Item($intRow,5).Font.Bold = $True
     $Sheet.Cells.Item($intRow,6) = "Data Used Space (MB)"
     $Sheet.Cells.Item($intRow,6).Font.Bold = $True
     $Sheet.Cells.Item($intRow,7) = "Log Name"
     $Sheet.Cells.Item($intRow,7).Font.Bold = $True
     $Sheet.Cells.Item($intRow,8) = "Log Size (MB)"
     $Sheet.Cells.Item($intRow,8).Font.Bold = $True
     $Sheet.Cells.Item($intRow,9) = "Log Used Space (MB)"
     $Sheet.Cells.Item($intRow,9).Font.Bold = $True
     $Sheet.Cells.Item($intRow,10) = "Log File"
     $Sheet.Cells.Item($intRow,10).Font.Bold = $True

    foreach ($db in $dbs) 
        {

          $dbname = $db.Name
          $fileGroups = $db.FileGroups

          ForEach ($fg in $fileGroups)
            {
       #   write-host $fg.files | select name
            If ($fg) 
                {

                    $intRow++

                    $mdfInfo = $fg.Files | Select Name, FileName, size, UsedSpace
                    $Sheet.Cells.Item($intRow,2) = $dbname
                    $Sheet.Cells.Item($intRow,3) = $mdfInfo.Name
                    $Sheet.Cells.Item($intRow,4) = $mdfInfo.FileName
                    $Sheet.Cells.Item($intRow,5) = ($mdfInfo.size / 1000)
                    $Sheet.Cells.Item($intRow,6) = ($mdfInfo.UsedSpace / 1000)

                    $logInfo = $db.LogFiles | Select Name, FileName, Size, UsedSpace
                    $Sheet.Cells.Item($intRow,7) = $logInfo.Name
                    $Sheet.Cells.Item($intRow,8) = ($logInfo.Size / 1000)
                    $Sheet.Cells.Item($intRow,9) = ($logInfo.UsedSpace / 1000)
                    $Sheet.Cells.Item($intRow,10) = $logInfo.FileName
                }
            }
        }
        $intRow++
    }
    $Sheet.UsedRange.EntireColumn.AutoFit()

The sqlserver.txt file is just a list of server names, one name per line with no punctuation as shown here;

testserver1 testserver2 testserver3

The first four lines in the script create the Excel spreadsheet. Then for each server in the sqlserver.txt file we use the Microsoft.SQLServer.Management.SMO.Server class to create a server object of SQL Server. From the server object we can get the databases, $dbs=$s.Databases, on each server. The next several lines in the script set the values in the columns of the header row in the spreadsheet. The section of the script starting with foreach ($db in $dbs) is the part of the script that actually gets the database file data and writes it to the spreadsheet.

Shown below is the resulting spreadsheet. I broke the spreadsheet image into 3 images for readability.

The first four lines in the script create the Excel spreadsheet
The next several lines in the script set the values in the columns of the header row in the spreadsheet
the resulting spreadsheet

In my next tip I will describe the process for getting the data into a database using SSIS then reporting on that data. Please stayed tuned.

05/23/2012 Posted by | Powershell, Sql Server | , | 2 Comments

%d bloggers like this: