Removing First Exchange 2010 Database

I Installed Exchange on my lab and wanted to do some testing for HA and DR in Exchange 2010. When first exchange 2010 Server by default it will create one Database by default.

Figure 1. First Exchange 2010 Database

Before I start my testing wanted to make sure that I have all the database created in the right location with the right name. Then I created a new Database on the exchange Server and moved all the mailboxes from the default first database to the newly created database and then I tried to delete the Default first database , immediately I got the below error. Figure 2.

Figure 2. Error when tried to delete First Default Exchange 2010 Database

Then wanted to check if I have any arbitration mailboxes left on the exchange server and executed the command and found that I had couple of arbitration mailboxes Figure 3.

Get-mailbox -Database "Mailbox Database 1475616347" -Arbitration

Figure 3. Command to get the list of Arbitration Mailboxes on Default First Exchange 2010 database

Unless we move it out these arbitration mailbox we will not be able to delete the Default Database. Used below command to move the database out to the new Database which i manually created with the name MDB01. Figure 4. Below Powershell command get all the arbitration mailbox and pipe to New-MoveRequest to move the mailbox to the new database

Get-mailbox -Database "Mailbox Database 1475616347" -Arbitration | New-MoveRequest -TargetDatabaes MDB01

Figure 4. Moving Arbitration Mailbox to the New Database

Once we have moved out, now we are ready to delete the database. This can be done either through console or through powershell command. Once you enter this command on the Exchange management shell console and confirm the same

Remove-MailboxDatabase "Mailbox Database 1475616347"

Exchange 2007/2010 Dynamic Distribution List filter customizing

As the name says Dynamic Distribution List is the group which maintains the list of users in the group dynamically. Every time it’s hard to maintain Static list. Static list needs to be manually managed for adding and removing users. If it’s the smaller list then it can be managed easily and if the group is very big and it bigger the problem

Dynamic Distribution list is can be created using Exchange management Console or Exchange management shell. Dynamic Distribution list manages the users using filter condition. Default filter condition provides us limited filter options like State, Department, Company, and other custom attributes like 1 to 15. Same has been shown in Figure 1.

Figure 1. List of Condition Options for filtering members to group

With this option we can build the Dynamic DL and these options some times can match our requirement and some times it may not.

For example we need to build a Dynamic DL with the list of users belonging to the specific Mailbox Server. Requirement option can vary depending on the business. Here i am just trying to take one example and explaining the concept.

Dynamic DL saves all the filters in the Active directory. AD Attribute msExchQueryFilter, msExchDynamicDLFilter has all filters settings.

msExchQueryFilter:
msExchQueryFilter hold the OPATH filters. OPATH is basis for the filtering syntax used by Powershell.

msExchDynamicDLFilter:
msExchDynamicDLFilter hold the LDAP filter which is available in msExchQueryFilter attribute

If we wanted to change the filter to match the requirement then we need to use ADSI Edit and edit the AD attributes and apply the new filter.

1. Access ADSI Edit from your computer and connect to Default naming context. Figure 2

Figure 2. connecting to Active Directory – Default naming context

2. Create the Dynamic DL in Advance and Browse the Adsiedit to the Dynamic DL which is create and right click and properties

3. Copy and paste the below OPATH filter on msExchangeQueryfilter and replace server name with the mailbox servrname, if clusterd then cluster CMS name

(((RecipientType -eq ‘UserMailbox’)) -and (-not(Name -like ‘SystemMailbox{*’)) -and (-not(Name -like ‘CAS_{*’) -and (ServerName -eq ‘Servername’)))

4. Now you have configured the filter. If you wanted to see if this filter is applied then you can use the below Powershell cmdlet. Replace DymamicDL with the name of the DL which we have worked on and it will get the result of all the users’ name that belongs to the specific server.

$DynamicDL = Get-DynamicDistributionGroup -Identity “DynamicDL”

Get-Recipient -RecipientPreviewFilter $DynamicDL.RecipientFilter |select name,servername

You can get this requirement if you wanted to send communication to specific users on the specific server when there is any maintenance etc. As I said earlier we can use similar filters based on the requirement to add users dynamically into the list. Technically you can get any Powershell filter into Dynamic DL

Tips on Quest and Exchange Shell to Manage Groups and Group Members

Tips on Quest and Exchange Shell to Manage Groups and Group Members

Groups are of two types Security groups and Distribution Groups. Securities groups are normally used in provide AD Object Permission and NTFS permission and Distribution groups are used to email members of the Distribution Groups or shortly we call it as DL (Distribution List). Security groups can also be enabled as mail enabled security groups that used for Setting Permission and also sending email to the Members of the groups

Figure 1. Details of the Security Groups in Quest Shell

If you wanted this security group to mail enabled so that users can send email to the members of the group once this it enabled this group will also be visible in the GAL. You can only enable universal Security groups. Enable-DistributionGroup Exchange cmdlet does this for us

Figure 2. Exchange Cmdlet to enable Security group to mail enabled security group

Nested Groups is always Challenging. If you are working Nested group and you wanted to find the list of Indirect Nested groups which this group belongs, below Quest cmdlet gets the details

Get-QadGroup <groupname> | Select NestedMemberof

Figure 3. Cmdlet to get the list of Nested member DL

To get the list of DL which this group is member of then

Get-QadGroup <groupname> | select Memberof

Figure 4. Cmdlet to get the list of DL which DL is member of

Groups will always have members and in it. Get-QadGroupsmembers <groupname> will get the list of all the members in it. Members can be a users, group, contact. In the below example usergroup5 has type group “usergroup4” as member. But usergroup4 also has members in it. Those members can be users or groups. Using -Indirect parameter provides the list of all the Direct and Indirect members of the group. This is so simple right. If you wanted to do that same in VBscript we need to write lots of codes may be a recursive finding to find al the members in the nested groups.

Figure 5. Cmdlet to get Direct and Indirect members of the Group

Lets now try to filter out only required object like users or groups or contacts from the Group members. Below powershell cmdlet will get the list of all the -Indirect members and it filters out and displays only members of type Group

get-qadgroupmember usergroup5 -indirect | ?{$_.type -eq “group”}

Same can be done using LDAP filters but this time lets try to get indirect members of type users

get-qadgroupmember usergroup5 -indirect -ldap “(objectCategory=user)”

If you wanted to find the count of all the users in the group then below command does it for us. This uses ldap filter to find the count

@(get-qadgroupmember usergroup5 -indirect -ldap “(objectCategory=user)”).count

Figure 5. Cmdlet gets the count of all the Indirect users in DL Usergroup5

Similarly if you wanted to find the count of group members then we can also use where command to get the count

@(get-qadgroupmember usergroup5 -indirect | ?{$_.type -eq “group”}).count

Figure 6. Cmdlet gets the count of all the Indirect groups in DL Usersgroup5

Another Interesting way to get the Members of the Group and the member count

Below powershell cmdlet gets the list of all the members CN name using get-Qadgroup

(get-Qadgroup usergroup5).members

In the same fashion we can also get count members just by suffixing with .count

(get-Qadgroup usergroup5).members.count

 

Exchange 2010 Connectors

Exchange 2010 Connectors

Introduction

A connector, as its name implies, is used to communicate between Exchange 2010 and External Entities like Internet Email Servers, legacy Exchange servers, 3rd Party mail servers, applications, appliances etc. Understanding this will help to create and configure various connectors and configure for the communication. This also helps on how mail flow can happen between exchange and other external entities.

This article is for all administrators on how to create and configure connectors and the application of the connectors. I thought of putting all the connectors will help to get some clear understanding of mail flow between Exchange and other email communication word.

Below are the various connectors which can be created and configured in Exchange 2010 Servers. Let’s understand one by one

– Send connector

– Receive connector

– Foreign (Delivery Agent) connector

– Linked connector

– Routing Group connector

Send connectors

A Send connector is basically used to send email to Internet Servers (i.e. servers outside of your own organization), and it controls how email should be passed to the “outside world”. No send connectors are created by default during the installation and setup of your Exchange server roles, and at least one needs to be created manually, which is a process we’ll look at in just a moment.

While there are invisible Send connectors which are created by default, these are used for mail delivery within the Exchange 2010 organization, and we have no control over them. Send connectors which we manually create must be created on a Hub Transport server, and are stored in the Active Directory. This information is therefore accessible to any Hub Transport Servers in the organization, which can then use this connector to send the email to the Internet word.

Multiple Send connectors can be configured to send email outside your organization. Multiple send connectors can be created with different cost for sending emails through different ISP Connection. This helps when you have multiple ISP connection and when there is failure of one ISP then you can use different Send connectors to route the email to the Internet. Multiple send connectors also help when you want certain traffic routed using a different connector. For Example you wanted to send email to Microsoft.com using a specific ISP connection and email to Simple-talk.com using a different ISP connection then different send connectors come in handy.

In addition, the Hub Transport server can be configured to send email to directly to the recipient, or it can direct outgoing email to a smart host (which can be an Edge Server or any application like Borderware, Postini, ironport etc.). If it’s configured to send email directly, then we need to make sure that the DNS is properly configured so that it can resolve internal and external DNS MX records. On the other hand, if it’s configured to send email to a smart host, then naturally the smart host should be configured to deliver the email to the Internet. Let’s take a look at how to set these options up.

How to Create and Configure Send Connectors

There are two ways to create a Send connector; via the Exchange Management Console or the Exchange Management Shell. Both methods end up with exactly the same result, you just need to pick the process you feel more comfortable with.

Via the Exchange Management Console

Open the Exchange management console and navigate to the result pane under Organization Configuration > Hub Transport Server. Select the Send connectors tab, and click on New Send Connector within the Action pane.

Figure 1. Creating a new Send Connector within the Exchange Management Console.

Now you need to go through a few configuration steps to make sure the new Send connector is correctly set up.

1) Specify the intent of the Connector

Providing a unique name which describes the connector’s purpose, particularly if you have multiple connectors, will help you to identity and differentiate specific connectors. Once you’ve given the connector a name, you need to specify its intended use:

Custom: Custom options are used when you wanted to send mail to a specific domain which is not an Exchange Server. Custom connectors are used for forwarding messages to a smart host, which are configured to use DNS MX records to deliver the email to their destination.

Internal: Internal connector is used when you want your Exchange Server to communicate with other Exchange severs in different forests. Eg. If there are multiple Exchange forests in your organization and you want communication between the multiple forests to follow a specific path then an Internal connector is the way to define that path.

Internet: An Internet connector is used to send email directly to the Internet, and is configured to use DNS MX records to route email to its destination. This will be created on the organizations Internet-facing server(s) in order to deliver email. This option is generally used when you do not use a smart host to deliver email.

Partner: The Partner connector is, unsurprisingly, used to send email to a partner domain. For example, if a one company acquires another, then there may be business requirements that need these two companies to run independently, but they also want to make sure that emails shared between these domains are not sent over the public internet. This is when the partner Send connector comes into effect.

More in-depth information on the Intended options can be found on Technet.

Figure 2. Specifying the intended use of your Send connector

2) Specify the Address Space

Once you’ve specified the purpose of your Send connector, we have to state the domain address space to which the connector will be used to send mail:

– A “*” in the Address indicates that this connector will route all domains that do not match the internal organization’s list of accepted domains.

– “Domain.com” in the address indicates that this connector is dedicated to sending email to domain.com addresses.

– “*.Domain.com in the address space indicates that this connector is used for sending email to recipients in domain.com and any sub-domains.

Cost is used to set the priority of this connector, used when two or more connectors are configured for the same address space. The lower the cost higher the priority.

– A Scoped Send connector identifies which Hub Transport servers can use this connector. Send connectors are objects stored in Active Directory and, as they are also an organization configuration object, can normally be used by any Hub Transport servers in the organization. If you want to restrict the scope of the Send connector, so as to limit its use to just within the AD site of the Hub server it was created on, then this option needs to be checked.

Figure 3. Configuring the address space of the new Send Connector

3) Configuring the Network Settings

The Network Settings determine how the message is to be routed to the destination SMTP server, and they can be configured to work in one of two ways:

1. Use DNS MX records to route mails automatically.

2. Route mails though to one or more smart hosts and let them handle the rest of the delivery.

The option to use Domain Name System MX records to route email automatically should be taken when you want your Send connector to talk directly with the destination SMTP server’s gateway and deliver the emails to that destination gateway itself. You need to make sure that DNS is properly configured for the server to resolve the Destination MX Records. This option is only available when you have selected Custom, Partner or Internet as your connector intent in step 1, above.

Alternatively, if you select the route mail through the following smart hosts option, you will need to supply one or more IP addresses or the FQDN of the smart host which is going to accept the email from this connector. Obviously, you need to make sure that the smart host is capable of delivering emails to the destination SMTP server.

If this send connector needs to resolve remote domains using External DNS server then check "Use the external DNS lookup settings on the Transport Server" as shown in Figure 4. When you use this check box you also need to make sure the each Hub Transport servers which communicates with the Internet hasits ExteernalDNSServers configured. To Configure External DNS servers on Hub Transport Servers, the command is:

Set-TransportServer <ExchangeServer> -ExternalDnsServer <ExternalDNSIPaddress1>,<ExternalDNSIPaddress2>

Figure 4. Specifying IP addresses for smart hosts.

Configuration of the connection(s) to the smart host(s) requires some additional steps to control authentication with the smart host server(s). The options available are:

None : The smart host does not require any authentication, and it accepts anonymous connections.

Basic Authentication: You will need to provide the smart host with an appropriate username and password to authenticate the connection. If you have multiple smart hosts, then you will need to make sure that they all allow access to the same username and password. Basic Authentication sends the credentials as plain text, and checking Basic authentication Over TLS will enable encryption on the communication.

Exchange Server Authentication: This option authenticates the connection to a smart host using an Exchange authentication mechanism, such as TLS direct trust or TLS\Kerberos.

Externally Secured:   Select this option if the connection to the smart host is secured by external means, such as being physically secured over a private network or secured using Internet Protocol security (IPsec).

Figure 5. Authenticating the connection to the smart host.

4) Source Server Settings.

This is the final configuration step in which you need to identify which severs will be making use of the new connector to route emails. Adding only required servers helps to ensure that only specific servers are able to participate in email delivery to the Internet or other partner networks. Adding the required servers is simply a matter of clicking the Add icon at the top of the configuration pane, and supplying the necessary server names and details.

Figure 6. Specifying which servers will be using the new Connector

5) Create the Send Connector

Once you’re done with the configuration, then you can just click Next and then New to create the new Send connector. At this point, we are pretty much done with the creation of send connectors through the Exchange management console.

Figure 7. The newly-created Send connector, configured and active.

Exchange Management Shell

Creating the Send connector in Powershell is pretty easy, because it’s just a single command, although naturally you need to make sure the parameters are correctly provided. Below is the simple command to create the Send connector for sending mail to the Internet, and it will create exactly the same connecter as the one we created using the console.

New-SendConnector -Name ‘To Internet’ -Usage ‘Custom’ -AddressSpaces ‘SMTP:*;1’ -IsScopedConnector $false -DNSRoutingEnabled $false -SmartHosts ‘[192.168.1.100]’,'[192.168.1.101]’ -SmartHostAuthMechanism ‘None’ -UseExternalDNSServersEnabled $false -SourceTransportServers ‘KEXCH’

Post-Creation Configuration

There are some important configurations which you should consider after creating your Send connectors; specifically, things like MaxMessageSize, SMTPMaxMEssagePerconnection, Protocollogging etc. Adjusting these configurations on a Send connector can be easily done using the set-Sendconnector cmdlet:

Set-Sendconnector -Name ‘To Internet’ -MaxMessageSize 20 MB -smtpmaxmessageperconnection 25

If you’re not sure how your Send connector is configured, using the Get-Sendconnector cmdlet will give you more information on the connectors, which you may want to take a look at in order to better understand them:

Get-senderconnector -name "Connector name" |format-List

Receive Connectors

As the names suggests, this connector is used to receive incoming email from other Exchange servers, the Internet, partners, etc. Receive connectors are dependent on the Hub Transport Servers, and each Hub Transport server is created with two receive connectors; a default Receive connector (for SMTP) and a client Receive connector (for POP3 and IMAP)

Figure 8. The two default Receive connectors on the Hub Transport Server role.

Each of these connectors has a specific configuration which we will take a look at shortly, and you can also create custom Receive connectors on the Hub Transport servers to act as secure relays within your organization. Each connector is associated with a local IP address and port number, and it’s also useful to define the IP address or range of IP addresses that a receive connector can accept connections and emails from, as well as the maximum message size, necessary authentication, permissions etc.

Initial Receive connectors on the Hub Transport Servers

As you can see in figure 8, each Hub Transport Server has two initial Receive connectors already in place: The default connector (for handling incoming SMTP email) and the client connector (for handling SMTP relay email). Both of these are configured to be secure by default, and it’s generally a good idea to keep them this way. Anonymous users permission is not enabled by default. Let’s take a closer look at these two connectors now:

Client [ServerName]

This connector is created when installing a Hub Transport server, accepts email from non-MAPI clients for SMTP relay, and is configured to use port 587. It can accept messages from any IP address and has permission to accept mail from Exchange Users, as they are basically authenticated users. The available authentication methods for use with this connector are: Transport Layer Security (TLS), Basic authentication, Exchange Server authentication, and Integrated Windows authentication. Only Exchange users have permission to use this connector.

Default [ServerName]

Also created upon server installation, this connector is configured to accept email from other hub servers and other servers on port 25 (the universal SMTP port). This connector is also configured to accept messages from any IP address, and it is configured with permissions for use by Exchange users, Exchange servers and legacy Exchange servers. The available authentication methods are: TLS, Basic authentication, and Integrated Windows authentication. Exchange users, Exchange users , Exchange Servers and Exchange Legacy Servers have permission to use this connector.

Custom Receive Connector

If you wanted a specific application server to be able to send email to an Exchange server then you can create a custom receive connector to accept email only from the specific application server. Configuration of Receive connectors to accept email from specific server and port is very important from a security point of view. This is so that we don’t allow any other application (such as a malware application) to use Exchange servers to relay email. To better understand Various configuration options available, let’s create a custom receive connector to suit our requirement and secure it.

First, access the Exchange Management console and navigate to Server Configuration > Hub Transport. Select the required Exchange Hub Transport Server from the upper result pane, and click on New Receive connector in the action pane Figure 9.

Figure 9: Starting the Receive connector creation process.

1) Specify the Intent of the Connector

As when creating a Send connector, provide a unique and appropriate name for the connector, and you now have various options for the connector’s intended use: Custom, Internal, Internet, Client and Partner. Each configuration has options for how clients can authenticate, interact with the local network, port configuration, the remote IP address range which can uses the Receive connector, etc. Let’s look at what each of the options provides us with:

Custom: This selection provides the most flexible options to create and configure receive connectors. Eg. Custom is selected when you have specific application requirements for communicating with Exchange on a different port.

Internet: This connector is open to messages from the Internet, and this setting provides the options to manage the connector’s local network IP addresses, ports and specific FQDNs, as well as providing anonymous and TLS authentication options.

Internal: This option only allows you to actively restrict which local network IP addresses can use this connector. This setting also provides options for TLS and Exchange server authentication, as well as permissions for Exchange servers and legacy Exchange servers.

Client: This setting only provides you with the option to change remote IP address settings. All Exchange users have permission to use this connector, and this setting also provides options for TLS, and also basic authentication with a TLS connection.

Partner: Similar to the “Custom” setting, “Partner” provides the option to manage the connector’s local IP addresses, FQDNs and ports, as well as the accepted remote IP address range. However, it only provides permission to partners, and provides TLS and enables domain security authentication.

Figure 10. Specifying the intent of the new Receive connector.

2) Modifying the Local Network Settings

The next step in creating the custom receive connector is modify the local Network settings with the connector’s IP address (es) and specified FQDN details. As you can see from the text in figure 11, these settings control which IP addresses and ports the connector will use to receive mail.

Figure 11. Defining the connector’s local network settings.

3) Managing the Remote Network Settings.

The next step is to control the range of remote IP addresses which can use this connector;:

Figure 12. Controlling the range of remote IP addresses which the connector will receive mail from.

4) Create the Receive Connector

Once you are done with configuring your custom Receive connector, follow the final instructions of the connector creation wizard, and you should be able to see the new connector alongside the others in the Exchange Management Console:

Figure 13. The newly-create Receive Connector

Exchange Management Shell

Creating the Receive Connectors in Powershell is pretty easy, because it’s just a single command, although naturally you need to make sure the parameters are correctly provided. Below is the simple command to create the Receive Custom connector for Receiving email on port 25, and it will create exactly the same connecter as the one we created using the console.

New-Receiveconnector -Name ‘From App’ -usage ‘Custom’ -Bindings ‘192.168.1.102:25’ -fqdn ‘mail.k.com’ -remoteIPrantes ‘10.10.10.1-255.255.255.0’ -Server ‘KEXCH’

Post Creation Configuration

Once this connector has been created, you can still manage and configure it either by right-clicking on it and examining its properties, or by using the set-receiveconnector Powershell cmdlet to do the same. The settings which are most worth your time are the various authentication options available and required for incoming connections, such as:

Basic authentication

In Basic authentication username and password is send in clear text which is not recommended. It is always advice to select the check box Office basic authentication only after starting TLS. Once this check box is enabled then first TLS connection is established between Exchange and other entity and then basic authentication is performed.

Integrated Authentication

When Integrated Authentication is checked then NTLM and/or Kerberos are used for authentication

Exchange Server Authentication (Generic Security Services application programming interface (GSSAPI) and Mutual GSSAPI).

This is used when you wanted Smart host to authenticate using TLS direct trust or Kerberos through TLS

Externally Secured,

Using this security mechanism that’s external to Exchange. The connection may be an Internet Protocol security (IPsec) association or a virtual private network (VPN)

Figure14. Defining the authentication options for a Receive connector.

Once you are done with the authentication settings, now its time to configure permission groups. First of all we need to make sure that we don’t enable anonymous users which will allow this connector as open relay. So that any one cannot use this connector with out appropriate rights. Other options available are Exchange users, exchange servers, legacy exchange servers and partners.

Exchange users – Offers Basic Authentication over TLS for connection

Exchange users and Exchange servers – Offers TLS and Exchange Server authentication

Partner Permission – offers TLS  and Enable Domain Security (Mutual Auth TLS) authentication. When you want a receive connector to receive email from a partner company over a TLS connection. More information on configuring Mutual Auth TLS can be found in TechNet.

Figure 15. Defining the Permission Groups allowed to use this connector

As already mentioned, Get-Receiveconnector also provides access to these settings, in case you prefer to use the Exchange Management Shell. Some of the options which are worth paying attention to are things like banner, maxinboundconnections, connection timeout, and protocol logging.

-MaxInboudconnections

This setting is to determine the maximum number of connections a receive connector can process at a single time.

-ConnectionTimeout

Connection Time out specifies how long connection can be established with the exchange server before it can Timeout.

-ProtocolLogging

Determine whether auditing is enabled on the connector. If is enabled then all the connection details and other related details will be logged. This can be very useful for troubleshooting issues.

-Banner

Banner is the message which is displayed when a connection is initiated with the Exchange server. The default banner can give server details. If you don’t want this information to be displayed then this can be changed using Set-Receiveconnector.

Figure 16. a screenshot of just some of the information available through get-receiveconnector.

If you want to modify a Receive connector, the Set-Receiverconnector cmdlet provides you with a quick method for doing this. You can find extensive documentation of this cmdlets parameters and switches in this TechNet article, but here’s a simple example:

Set-ReceiveConnector -Identity "Internet Receive Connector" -Banner "220 Banner Text here" -ConnectionTimeout 00:15:00

Foreign Connectors

Foreign connectors are used to communicate with 3rd party systems, but rather than use SMTP to communicate with these systems, it uses drop directories to communicate. For example, if Exchange 2010 wants to communicate with such a 3rd party system (which could be a server or an application), then it leaves the message in a drop directory on the Hub Transport server or Network Share. The 3rd party application then retrieves the message from the drop directory, and processes the emails.

Alternatively, if a 3rd party application wants to send a message into Exchange 2010, then it performs a similar action using the replay directory, which exists on the Hub Transport server; correctly formatted email message files that are copied to the Replay directory are submitted for delivery.

Foreign connectors are stored in Active directory and are available to all the Hub Transport servers in the organization, which then use foreign connectors to route emails to destination folders for a given address space. For redundancy, multiple Hub Transport servers can be added to the connector, so that if one server fails or is otherwise unavailable, then the email will be routed using an alternate Hub Transport server.

In Exchange 2010, foreign connectors use Delivery Agent connectors to route email to the foreign systems. Delivery Agent connectors ensure that the messages intended for foreign systems are inserted into the appropriate queues on the Hub Transport servers that are used for delivering such messages. After the messages are queued, the delivery agent is invoked by Connection Manager, and the agent handles the actual delivery of the message to the foreign system.

Creating and Configuring a New Foreign Connector

For the sake of speed, we’ll handle this task using the Exchange Management Shell; once you’ve got the shell open, we run the New-Foreignconnector command, which is extensively documented on TechNet:

New-Foreignconnector -identity "ForeignConnector" -AddressSpaces "fax:*" -SourceTransportServers "Hub01.domain.com","Hub02.domain.com"

In Figure 17, we are trying to create a foreign connector for the Fax application, with the address space “Fax:*”, and making use of just a single Hub Transport server called “Kexch”. Naturally, any fax messages would use this connector:

New-Foreignconnector -name "foreignconnector" -addressspace fax:* -sourcetransportserver Kexch

Figure 17. Running the New-Foreignconnector cmdlet, and seeing the results.

Once you have created the connector, you can easily modify it based on your requirements using the Set-foreignconnector cmdlet. Below I have specified the drop directory for my new connector, and set the maxmessage size to 10 MB.

Set-Foreignconnector -Identity "Foreignconnector" -Maxmessagesize 10MB -dropdirectory C:\DropDirectory

Linked connector

As the name suggests, this is a situation where a Receive Connector which is linked to a Send connector (and so it is a relationship, rather than an actual connector in itself), and it exists for a very good reason. This connector is used when you have 3rd -party anti-spam and anti-virus systems (such as postini) processing your messages at a vendor’s location or on a different server. In that situation, you need to ensure that all the incoming email passes through the 3rd party appliance, and then receive those emails back once the email scanning and filtering is completed, and this is what the Linked connector enables.

Linked connectors are created on Hub Transport or Edge Transport Servers and, thankfully, can be used without changing your existing configurations, such as your MX records, Sender Policy Framework etc. Let’s look at how we can create Linked connectors on the existing network:

Figure 18. Simple network routing topology, including a pair of Linked connectors routing messages to an anti-spam service.

Let’s take a quick look at the setup in Figure 18: Image Source

Sendconnector:25 and Receiveconnector:25 are the two connecters configured to send and receive all email between the internal network and the Internet. When we want our email to be scanned by anti-spam servers, we need to create and configure the connectors between our internal network and those external servers, and then create an appropriate link to our existing connectors to allow for that.

First, we need to create the new Sendconnector:26, and link it with the receiveconnector:25, and configure the Send connector to deliver incoming email (from step 1 in the image) to the anti-spam solution (step 2 in the image). Next, we need to create the new Receiveconnector:27 to receiving email back from the anti-spam solution (step 3), and deliver that email to the internal Exchange server, which will then distribute the email to the appropriate users (step 4).

That sounds simple enough, so let’s create the new sendconnector:26 and Receiveconnector:27 connectors, and configure the link between receiveconnector:25 and Sendconnector:26

Creating and Configuring Linked Connectors

In the command below, we are creating a new Send connector and using the linkedreceiveconnect command to link the new connector with the existing Receiver. The -SmartHosts parameter allows you to enter the details if the anti-spam server. DNS routing needs to be disabled. Normal send connectors are configured with DNS for delivering emails to the remote domains. This Send connector is linked with receive connector to forward email to specific server and there is no need for DNS routing, hence DNS routing is set to $false. Smart host authentication is set to Externalauthoratative. Extenalauthorative authentication is used when the connection is fully secured between exchange server and Smart Host (Anti Spam Server). Once Enternalauthorative is set then any client can connect to Exchange sever as Authorized Server. Below is the Powershell command to create new Send connector:26 and link with receive connector:25 to deliver all the incoming emails from the internet to smart host.

New-SendConnector -Name "Sendconnector:26" -LinkedReceiveConnector "Edge01\Receiveconnector:25" -SmartHosts antispam  -SmartHostAuthMechanism Externalauthoratative -DNSRoutingEnabled $False -MaxMessageSize unlimited

Now let’s create the new Receive connector for receiving email back from the anti-spam server. The new-receiveconnector cmdlet below creates a new connector with externalauthoratative authentication and the remoteIPrange set to the anti-spam server.

New-Receiveconnector -name "Receiveconnector:27" -AuthMechanism externalAuthoritative -RemoteIPRanges antispam

Routing Group Connectors

Routing Group connectors are connecters between Exchange 2010/2007 servers and Legacy Exchange 2003 servers for internal mail-flow between them. A RGC does not need to be created between Exchange 2010 and 2007, communication happens automatically. Bidirectional instances of these connectors are installed by default when you introduce a new Exchange 2010 Hub Server into the Exchange Organization. Or rather, are created during the installation; one each for mail flow between Exchange 2003 and Exchange 2010, and between Exchange 2010 and Exchange 2003.

Exchange 2003 uses a link state routing table to maintain routing information on how email is routed in organization, and this table is updated when the routing group master effects a change in the mail routes.

However, Link State routing isn’t used at all in Exchange 2010, which instead communicates with the Hub server directly and uses AD site cost to determine the shortest routing path. We can create multiple Routing Group connectors between Exchange 2003 and Exchange 2010, but if we do, we will need to make sure that Link state updates are suppressed so that message looping does not occur when route is recalculated.

Let’s take a look at how to create new Routing Group connectors, and also how to modify them to add additional source and target servers for redundancy in the event of a server failure.

The New-Routinggroupconnector cmdlet below creates a new Routing Group connector. In terms of settings, the Sourcetransportserver and TargetTransportservers need to be specified, and the Bidirectional setting controls whether this connector to allow for two-way or one-way mail flow. If bidirectional is set to $true, then two connecters will be created, as a reciprocal connector is created in the target routing group.

New-RoutingGroupConnector -Name "RGCBidirection" -SourceTransportServers "Hub2010a.domain.com" -TargetTransportServers "Bridgehead2003.domain.com" -Cost 100 -Bidirectional $true

For redundancy, we can add multiple source and target transport servers into the existing “RGCBedirection” connector using the Set-RoutingGroupConnector cmdlet:

set-RoutingGroupConnector -Identity "RGCBidirection" -SourceTransportServers “Hub2010a.domain.com”, “Hub2010b.domain.com” -TargetTransportServers " Bridgehead2003a.domain.com”,” Bridgehead2003b.domain.com"

And lastly, if you want to get the complete status on the newly created and configured routing group connectors, the you just need to use the Get-RoutingGroupConnector cmdlet like so:

Get-Routinggroupconnector -identity "RGCBidirection" | format-list

If you want a deeper understanding of the New-RoutingGroupConnector cmdlet, extensive details are once again available from Microsoft TechNet. Likewise, there is a huge amount of information available on the Set-RoutingGroupConnector and Get-RoutingGroupConnector cmdlets.

Conclusion

With this I would like to conclude my article. I hope this article is informative for the administrators to understand all the Exchange 2010 connectors, configuration and their applications.

In this article I have tried to create and configure connector using both Exchange management console and Exchange management shell. Creating and configuring using Powershell is always easy but we need to make sure that all the required parameters are used correctly. Some connecters like linked connectors cannot be created using Management Console, it always needs to created and managed only using Powershell. Creating and managing using management console provides with limited option. Powershell Set-* and Get-* cmdlets allows exploring various advanced option which cannot be done using management console. Set-* Powershell cmdlets allows connectors to be configured at a granular level.

Exchange 2010 – Allowing High Profile users to send and receive Bigger size attachment emails

 

There is always been the requirement that in any organization few users or High profiles users wanted to send and receiver bigger attachment. Bigger the attachment, bigger the challenges for the Administrators. It is recommended to keep attachment size smaller. Smaller the email faster will be processing both on the SMTP gateway servers and Hub servers. Bigger the attached size bigger the storage you need. These some of the few challenges as an administrator you may come across when users asks for bigger email attachments. Restricting the message size is important and some times in most times its been neglected. This can have a great Impact on the Exchange organization.

Lets understand this better with the below scenario and configure attachment based on new business requirement

Current Status

1. 100000 Normal users

2. 1000 High Profile Users

3. 10 MB of email attachment size for all

New Business Requirement

1. 1000 High profiles users should be able send and receive 30 MB attachment emails

2. Normal users should be able to continue with sending and receiving 10 MB size

attachments

We can implement this solution in two way, Now we need to really new think and decide which is the solution will ideally fit into our organization. You also need to consider to convent conversion when exchange converts from MAPI/Exchange format to Internal/ MIME Message format and vice versa. Content conversion normally increases the message size by 30 MB. This is really important which should not be overlooked.

Solution 1

This solution will be good for smaller origination

1. First we need to make changes with the Transport organization(Global) configuration.

Below command gets us the details of the current MaxSendSize and MaxReceiveSize limits set.

Get-TransportConfig | fl MaxSendSize,MaxReceiveSize

2. This Global configuration is applied to all the Exchange Hub Servers. To change this global configuration we can use blow commands. We can also set this MaxSize limits on the individual Hub Servers. Below is the example on how to Increase the MaxSend and MaxReceive Size limits on the Organization level

Set-TransportConfig -MaxReceiveSize 30MB -MaxSendSize 30MB

3. Exchange 2010 uses AD Site topology to determine the low cost path to route the email to the Destination if user is located in the different site. If Message to be delivered to the remote AD size is larger then the limits set on Site link then message delivery will be failed. By Default MaxMessageSize on the AD Site link is set to unlimited.

Get-Adsitelink <AdSitelink> | select Maxmessagesize

4. If we are changing the Maxsize limitation, its important that you need to check if there is any limits set on the AD site link and change it accordingly if required. Below is the command to set the new MaxMessageSize

 

Set-Adsitelink <Sitelinkname> -MaxMessageSize 30MB

5. To Send Bigger email to Internet we need to make sure that Send connectors is configured correctly with appropriate message size. To get the current MaxMessageSize configuration on the send connecters

Get-Sendconnector “To Internet” | fl Name,MaxMessageSize

6. To Set MaxMessageSize we can use powershell to command to set the same. This will allow users to send bigger attachment.

Set-Sendconnector “To Internet” -MaxMessageSize 30 MB

7. How about receiving bigger attachment email ? our requirement is that High profile users should also receive bigger attachment email from Internet. For this we need to configure receive connector which receives email from Internet. To Get the current size limit on receive connector, below is the command

Get-Receiveconnector -Identity “<Connectorname>” | fl Name,MaxMessagesize

8. To Set the MaxMessage size to 30 MB we need to use the below command for the connector which receives email from Internet

Set-ReceiveConnector -Identity “<connectorname> -MaxMessageSize 30 MB

9. With this we are almost done with the configuration on the organization and Connectors end. Now the Final Part is to set the Message Size restriction on the users mailbox. By default all users will be able to send and receive based on the global configuration. If any users wanted to send or receive bigger email then we need to Increase Sending and Receiving MaxMessageSize from mailbox configuration.

There is catch here which you should know

Setting Higher limits on the Individual recipients bypasses organization size limits but its only Internal. Users with Individual Higher limits cannot send and receive email from Internet (unauthenticated users)

 

This is reason why we have configured higher organization size limits, higher connecter limits for users to send and receive higher email. With Higher organization size limits all users will be able to send and receive bigger emails. We wanted only few users to have this higher limits and others to retain 10 MB size limits. For this we need to make changes on max size limit on individual mailbox configuration on all the mailbox except the high profile mailbox. As we have already discussed setting individual mailbox limits

will override the organization limits.

10. Below command get you the current Send and Receive Size configuration on the mailbox By Default it is set to unlimited. This setting uses the Global size limits

Get-Mailbox <mailbox> | fl MaxSendSize,MaxReceiveSize

11. To Set Size on the Individual mailbox limits you need to use the below mentioned command. As we have configured Global Max message size configuration to 30 MB, now we wanted to restricted all users except High profile to 10 MB limits. Below is the example to set on the Individual Mailbox and get the status

Set-Mailbox <mailbox> -MaxSendSize 10MB -MaxReceiveSize 10MB

 

12. We can use powershell commands to set all the mailbox size limit using single command. This is bit tedious right, you really don’t wanted to configure on every Individual Mailbox. I know we can do this easily with powershell but this would be ongoing and needs to apply for any new users. In the coming days if you wanted to apply the Bigger size limits for the Entire organization then you have change this configuration on every mailbox.

Below are the few cmdlets which helps to get where all the message size is applied and to get the current MaxMessageSize limits.

<em>Get-ForeignConnector | fl Name,MaxMessageSizeGet-SendConnector | fl Name,MaxMessageSizeGet-ReceiveConnector | fl Name,MaxMessageSizeGet-ADSiteLink | fl Name,MaxMessageSizeGet-RoutingGroupConnector | fl Name,MaxMessageSizeGet-TransportConfig | fl MaxSendSize,MaxReceiveSizeGet-DistributionGroup | fl name,MaxSendSize,MaxReceiveSizeGet-DynamicDistributionGroup | fl name,MaxSendSize,MaxReceiveSizeGet-Mailbox | fl name,MaxSendSize,MaxReceiveSizeGet-MailContact | fl name,MaxSendSize,MaxReceiveSizeGet-MailPublicFolder | fl name,MaxSendSize,MaxReceiveSizeGet-MailUser | fl name,MaxSendSize,MaxReceiveSize</em>

Solution 2

This solution will be good for Bigger organization

1. First we need to make changes with the Transport organization(Global) configuration.

Below command gets us the details of the current MaxSendSize and MaxReceiveSize limits set.

Get-TransportConfig | fl MaxSendSize,MaxReceiveSize

2. This Global configuration is applied to all the Exchange Hub Servers. To change this global configuration we can use blow commands. We can also set this MaxSize limits on the individual Hub Servers. Below is the example on how to Increase the MaxSend and MaxReceive Size limits on the Organization level

Set-TransportConfig -MaxReceiveSize 30MB -MaxSendSize 30MB

3. Exchange 2010 uses AD Site topology to determine the low cost path to route the email to the Destination if user is located in the different site. If Message to be delivered to the remote AD size is larger then the limits set on Site link then message delivery will be failed. By Default MaxMessageSize on the AD Site link is set to unlimited.

Get-Adsitelink <AdSitelink> | select Maxmessagesize

4. If we are changing the Maxsize limitation, its important that you need to check if there is any limits set on the AD site link and change it accordingly if required. Below is the command to set the new MaxMessageSize

 

Set-Adsitelink <Sitelinkname> -MaxMessageSize 30MB

5. To Send Bigger email to Internet we need to make sure that Send connectors is configured correctly with appropriate message size. To get the current MaxMessageSize configuration on the send connecters

Get-Sendconnector “To Internet” | fl Name,MaxMessageSize

6. To Set MaxMessageSize we can use powershell to command to set the same. This will allow users to send bigger attachment.

Set-Sendconnector “To Internet” -MaxMessageSize 30 MB

7. How about receiving bigger attachment email ? our requirement is that High profile users should also receive bigger attachment email from Internet. For this we need to configure receive connector which receives email from Internet. To Get the current size limit on receive connector, below is the command

Get-Receiveconnector -Identity “<Connectorname>” | fl Name,MaxMessagesize

8. To Set the MaxMessage size to 30 MB we need to use the below command for the connector which receives email from Internet

Set-ReceiveConnector -Identity “<connectorname> -MaxMessageSize 30 MB

9. With this we have almost done with the configuration on the organization level. Now all users where be able to send and receive 30 MB of email size but our requirement is allow only 1000 users to send and receive 30 MB emails. This can be configured with Transport rules

10. Before configuring Transport rules, lets create a Distribution group with list of High Profile users. Below is the command to create a new DL. Once you created the below DL then you can add the required(1000) users to this DL

New-DistributionGroup -Name ‘HighProfileUsers’ -Type ‘Distribution’ -Samaccountname ‘Highprofileusers’ -Alias ‘Highprofileusers’

 

11. Now lets create a new Transport rule. Open Exchange Management console -> Expand Organization Configuration -> Hub Transport Server -> on the Result pane click on Transport rules Tab -> click on New Transport rule on Action pane to create a new Transport rule

12. Provide Suitable name for the new transport rule. Providing the appropriate name is very Important. If there are multiples rules then name will help in easy identifying of the rules . Once this is done click on Next

13. Select option When the size of any attachment is great then or email to limit and enter the value 10240 (10 MB) on the below edit pane. This is shown in the below Image and click on Next

14. Select the option Send reject message to the sender with enabled status code and Enter appropriate Bounce messages and Error code. Enabling option will restrict users from sending email size with attachment bigger then 10 MB and if sends bigger email then this will be error message which users will be Getting. Make sure that you enter the appropriate Error message with the Status code. This message should be very clear that senders should be able to Identify the Issue and should send smaller attachment size.

Then click on Next

15. Here we select except when the message is from the member of the Distribution list and except when the message is sent to the member of distribution list and add the newly created DL to this exception. Here we are setting except the members of the DL. Except DL members other users will be to able to send and receive bigger attachment size email.

As we have excluded for DL members, now you may think what is the Max message for the DL members. Its 30 MB. This is the global configuration. Now DL members will come under global configuration. Only they can enjoy email with bigger attachment up to 30 MB. Need to make sure that any new High profiles users should be added to the DL so that they also enjoy 30 MB attachment restriction.

 

16. Click on new to create this new transport rule. Once this rule is create any email sent with higher attachment other than the members of High Profile users will get the bounce back messages with the custom message set in the transport rule

 

 

Idea of Transport rule is that any email send from mailbox goes to the Hub transport servers where email is categorized and it will applied again all the transport rules available. If any of the condition matches then according action will be taken based on the rules.

I think solution with Transport rule would be easy and Simple. Where in you don’t have the make changes on the every individual mailboxes and also if you wanted to scale this solution to every one in the organization then all you need to do is to just remove the transport rule. Then every one in the organization will be able to send and receive email of 30 MB size.

You have the choice to use both the solution and you are best person to decide which solution will ideally fit into your organization.

Removing public folder from Exchange 2007 Server

In Exchange life cycle we always bring in new Exchange servers and some times remove the old exchange servers. Some times decomission of exchange servers is bit challanging but really noting to worry. As you whould moved most of the users out and there will be no impact.

Once you remove public folder then most of the decomission goes smooth. Removing public folder some times can be bit tricky, in fact most of the time we have to fight with PF to remove it. Before removing the public folder you need to make sure that you remove all the replicas for that public folder Database.

This commands helps you get the list of all the public folder and there replicas

Get-publicfolder \ -recurse |ft Name,Replicas

This commands gets you all the system folders replicas

Get-publicfolder \NON_IPM_SUBTREE -recurse |ft Name,Replicas

If you wanted to move all the replica pointing from the decomission server to new server then below command does it all. Once you run this command you need to wait for some time. Time may vary, it can take few hours to days depending on the size of public folder.

.\MoveAllReplicas.ps1 -Server MySourceServer -NewServer MyTargetServer

If you dont wanted move the replica and some times all the pf folder will share the replica and it really does not make sense to move the replica to the database which already exists. Then you may wanted to use removereplicafrompfrecursive powershell script which is available in scripts, to remove all the replica for the server. Again it needs some time for the replication.

RemoveReplicaFromPFRecursive.ps1 –TopPubicFolder “\” -servertoRemove <servername>

Once all the replicas are romoved then you can delete public folder database using below command. Before that you also need to make sure that Mailbox database is not pointing to this PF database which you are removing

Get-publicfolderdatabase -server <decomservername> | remove-publicfolderdatabase

Exchange 2007/2010 – Custom System message – HTML format

Exchange 2010/2007 provides you the option to send the custom system messages. You can customize the message which users get when his mailbox quota is getting to close to the limits. Default warning message does give some information. If you wanted to add more data like steps to delete unwanted email, link to your internal email policy etc. These things can be done easily with new-systemmessage or set-systemmessage

Below is the example of the same. Remove-systemmessage removes the existing default warning message.

$K has all the data which you wanted to be in the warning message, it has link, message with different bold and colour. You can include any basic HTML stuff to format the data.

New-systemmessage helps us to assigning the HTML data into the system for warning mailbox

Remove-SystemMessage En\WarningMailbox$K=@"<BR><b> <font Size="3" color="RED" Face="Arial"> You will have problem sending email if you do not delete your unwated emil</b> </Font></BR> <br>Make sure that you delete your unwated and deleted items from your mailbox </br><br> <A name='Internalportal'>Company email policy</A></BR>"@New-SystemMessage -QuotaMessageType WarningMailbox -Language En -Text $K

VBscript to Add users to local administrator group for list of given computer list

 

Below script takes input as list of computer names in the txt file and also takes group name or user account which you wanted to all as member of Administrators in all the computer listed in the txt file

on error resume next
dim filesys,filetxt
const ForReading = 1
Complist = Inputbox("Enter the path of text file which has list of Computers")
Complist = trim (Complist)
if Complist = "" then
wscript.echo "You did not Enter any thing!! "
wscript.quit(0)
end if

GroupAdd = Inputbox("Enter the Group name which you wanted to Add to the local computer Group")
GroupAdd = trim (GroupAdd)
if GroupAdd = "" then
wscript.echo "You did not Enter any thing!! "
wscript.quit(0)
end if

Set filesys = CreateObject("Scripting.FileSystemObject")
set filetxt = filesys.OpenTextFile(Complist,ForReading)

group = "WinNT://boston/" & GroupAdd

do Until filetxt1.AtEndOfStream
strComputer = filetxt.Readline
strComputer = trim(strComputer)

Set objGroup = GetObject("WinNT://" & strComputer & "/Administrators")
objGroup.Add group
err.clear

loop

You can find the copy of the file from the below location

http://powershell.com/cs/cfs-filesystemfile.ashx/__key/CommunityServer.Components.UserFiles/00.00.00.30.62/AdAdminGroup.txt