SUKUM: Exchange Knowledge Sharing

Send Welcome Email to New Mailbox / New Users.

2013-04-03T11:43:00Z

Take Away:

- There are many ways to send welcome emails in Exchange 2010/2013.

- Using Cmdlet Extension is one of the ways to send welcome email.

- The blog explains how to setup Welcome email thru Cmdlet Extension.

Let’s understand how to configure Exchange Server to send welcome email:

What is Cmdlet Extension Agents?

Cmdlet extension agents are components in Microsoft Exchange Server 2013/Exchange Server 2010 invoked by Exchange 2013/2010 cmdlets when the cmdlets run. Every time an Exchange cmdlet is run, the cmdlet calls the Scripting Agent cmdlet extension agent. When this agent is called, the cmdlet checks whether any scripts are configured to be called by the cmdlet. If a script should be run for a cmdlet, the cmdlet tries to call any APIs defined in the script. Cmdlet extension agents are available on any server role.

For more information on this please refer the link : http://technet.microsoft.com/en-us/library/dd335054.aspx

Caution:

When you enable the Scripting Agent cmdlet extension agent, the agent is called every time a cmdlet is run on a server running Exchange 2010. This includes not only cmdlets run directly by you in the Exchange Management Shell, but also cmdlets run by Exchange services, the Exchange Management Console (EMC), and the Exchange Control Panel (ECP). We strongly recommend that you test your scripts and any changes you make to the configuration file, before you copy your updated configuration file to your Exchange 2010 servers and enable the Scripting Agent cmdlet extension agent.

Implementation:

As you got an idea on the Cmdlet Extension Agent, I will go ahead and explain how we can use the feature to generate welcome email for the new mailboxes that we create.

When we create new mailbox in Exchange 2010/2012, new-mailbox command is used (whether it is Exchange Management Shell or Exchange Management Console). You can enhance the behavior of the command by using Cmdlet Extension. It is like triggering a script whenever new-mailbox command is used.

In order to use the feature, we need to,

- Deploy XML file on all the exchange servers.

- Enable “Scripting Agent”.

How to deploy XML files?

On all the exchange servers, the exchange setup copies the file "ScriptingAgentConfig.xml.sample" to <installation path>\Bin\CmdletExtensionAgents\. The file is a kind of sample/template. We can modify the file to meet our requirement or we can make our own XML file. I have detailed the steps to modify the sample file to send welcome email.

Step #1:

Create a welcome email template in html format that will be sent as welcome email or use the exiting template attached to the blog to suit your requirement. Easiest way to create welcome email template would be, open new message in Outlook, compose the email and save it as HTML.

Step #2:

Make a copy of the existing XML file and rename it to ScriptingAgentConfig.xml. Keep the file in <installation path>\Bin\CmdletExtensionAgents\.

Step #3:

Copy and paste the below script into appropriate location inside the XML file and Save it. It can be inserted between </feature> …. <Feature Name ….> or at the beginning of the XML file (after <Configuration Version=”1.0”>).

# Script to send new email starts here

if($succeeded) {

# Using UserSpecifiedParameters to get new user email ID.

$USRdname= $provisioningHandler.UserSpecifiedParameters["Name"]

$USRalias = $provisioningHandler.UserSpecifiedParameters["Alias"]

$USRemail= $USRalias + "@e2k10.com"

# Locating welcome email template file and replacing place holder with new mailbox display name.

$tempmsg= [string] (get-content ("c:\welcome\WelcomeMSG.htm"))

$tempmsg = $tempmsg -replace "NewUser00",$USRdname

# Using HUB IP to process new mail request. Give your HUB server IP.

$HUBServer="10.1.1.2"

$WelcomeEMail = new-object net.mail.mailmessage

$HUBTask = new-object net.mail.smtpclient($HUBServer)

# Email to be sent from the address given in the following line.

$WelcomeEMail.From="administrator@e2k10.com"

$WelcomeEMail.To.add($USRemail)

# Email Subject and Body details are specified in following lines.

$WelcomeEMail.Subject="Welcome to Contoso IT !!!"

$WelcomeEMail.Body= $tempmsg

$WelcomeEmail.IsBodyHtml = $true

$HUBTask.send($WelcomeEMail)

}

</ApiCall>

</Feature>

# Script to send new email ends here

Step #4:

Make the necessary changes in the script to suite your environment.

**** Change SMTP domain *****

$USRemail= $USRalias + "@e2k10.com"

**** Give the path of the template file you created in Step #1. ****

$tempmsg= [string] (get-content ("c:\welcome\WelcomeMSG.htm"))

**** Give your HUB server IP address and Make sure that the HUB server accept connection ****

$HUBServer="10.1.1.2"

**** Give email address from which you want to send welcome message ****

$WelcomeEMail.From=administrator@e2k10.com

**** Change the subject of the welcome message, if you wish ****

$WelcomeEMail.Subject="Welcome to Contoso IT !!!"

What the script does?

When a new mailbox is created, on its successful completion, the script will be called. The script works along with email template available in "c:\welcome\WelcomeMSG.htm". It can be modified to meet your requirement.

To start with,

It stores the new mailbox user display name & alias in the variables, $USRdname, $USRalias respectively. Later it constructs email ID by concatenating alias + SMTP domain ($USRalias +“e2k10.com”). I opted for alias as it is commonly used email format. If email policy uses different format, you can change it.

Then it reads the content of template "c:\welcome\WelcomeMSG.htm" and stores in the variable $tempmsg. As the template is set with place holder "NewUser00", the script uses “-replace” to update the place holder “NewUser00” with the display name.

Later we create new message object and SMTP client object to send out email. Before we send the email, we compose the email with From address, To address, Subject and Body.

Welcome Email Template with Place Holder:

I have created template as shown in the Picture #1. The template is with place holder “NewUser00”. This will be replaced with display name when the email is sent (as shown in Picture #2).

Picture 1

Welcome Email after place holder replacement:

Picture 2

How to manage/enable Cmdlet Extension Agent?

After the XML file updated with script, you need to enable the agent to call the XML file and the script whenever new-mailbox used. You can view the agent status by running the command: Get-CmdletExtensionAgent | FT Name,Enabled

By default,“Scripting Agent” is disabled. You can enable it using the command,

Enable-CmdletExtensionAgent "Scripting Agent"

When you wanted to disable the “Scripting Agent” , run the command ,

Disable-CmdletExtensionAgent "Scripting Agent"

Enabling or disabling CmdletExtension does not require restart of the server or exchange services in a normal scenario. It is a global command and applicable to all the exchange servers in the organization. So you have to update the XML file on all the exchange servers. If the XML files is not updated on any of the exchange server and you run any non-Get cmdlets, the cmdlet will fail.

For More Information on managing Cmdlet Extension, please refer the link : http://technet.microsoft.com/en-us/library/dd298143.aspx

Test:

As both script and agent are in place, you can create new mailbox using EMC or EMS and check how it works. You may notice that the mailbox creation is taking little bit longer than it used to. That’s because the additional activities are done along with new-mailbox.

Related articles :

http://technet.microsoft.com/en-in/library/dd297951(v=exchg.141).aspx

http://technet.microsoft.com/en-in/library/dd335067(v=exchg.141).aspx

http://technet.microsoft.com/en-us/library/dd298143(v=exchg.141).aspx

Exchange DSAccess / ADAccess and AD site Link

2013-02-08T10:46:00Z

By writing the article, I hope that you will be able to understand the criteria considered by DS Access to list GCs in Event ID 2080. The article will allow you to ensure continuity in case of a server failure.

I will start by listing how DS Access/AD Access identifies the topology by using the following steps for the benefit of Exchange administrators:

The system attendant process, mad.exe, instantiates and initializes DSAccess.dll during startup.
From the local domain, DSAccess opens an LDAP connection to a randomly chosen Domain Controller (DC). This DC is referred to as the bootstrap server.
DSAccess reads the local registry to determine if the topology is hard coded. If the topology is hard coded, the discovery process stops. If no hard coding is detected, DSAccess continues the discovery process.
DSAccess queries the bootstrap server to identify local DCs and Global Catalog servers (GCs). DSAccess then determines server suitability and assigns server roles.
DSAccess queries the bootstrap server to determine if one or more secondary sites are connected to the local site. If secondary sites exist, DSAccess sorts the siteLink objects for each site from lowest cost to highest cost. DSAccess places the lowest cost sites in a secondary topology list.
DSAccess queries the bootstrap server to identify the DCs and GCs that are located in the secondary topology sites.
DSAccess identifies the full topology and compiles a list of working domain controllers and a list of working GCs.

There are situations when Exchange DS Access/AD Access does not show the GCs from other AD Sites in Event ID 2080. As an Exchange administrator, you may be wondering why the event 2080 does not list all GCs in the domain even though the GCs are healthy. To save you a lot of production downtime and effort, I will discuss the following aspects.

Exchange DS Access/AD Access uses AD Site Link details while listing GCs in Out-Of-Site in Event ID 2080. If there is no direct site link between AD site where Exchange exists and other AD sites, the AD sites' GCs will not be considered to be listed in Event ID 2080.

I thought that giving an explanation on AD site link criteria used by DS Access/AD Access will help you to manage the GC resource efficiently for better Exchange functionality.

Since a picture is worth a thousand words, I will explain the topic in question using examples and diagrams.

Let’s say we have the following lab setup:

Four AD sites named Site A, Site B, Site C, and Site D
All sites belong to a domain – CONTOSO.COM
Each site has two GCs
The Site A is installed with Exchange server
There are direct AD Site links between Site A and Site B, Site A and Site C, Site A and Site D

Picture 1

Scenario 1:

The Site A, the Exchange site, has direct AD site link with other AD sites. All site links have the same site Link Cost i.e. 100. So, the Event ID 2080 on Exchange will appear like in the following snapshot, Picture 1A:

Picture 1A

Scenario 2:

If I change my AD site Link Cost as shown in Picture 2, then Exchange will pick the GCs from the Site with lowest cost to list under Out-Of-Site in Event ID 2080 and will ignore other AD Site GCs.

Picture 2:

Exchange will consider only the Site Link with lowest cost for the Out-Of-Site GCs. So, the Event ID 2080 will look like Picture 2A.

Picture 2A

Other GCs in Site B and Site C will not be listed in Event ID 2080. Therefore, Exchange will not use the other GCs i.e. GC5, GC6, GC7 and GC8 in sites B and C.

Scenario 3:

If I change my AD site Link as shown in Picture 3 then Exchange will pick the GCs from the Site C to list under Out-Of-Site in Event ID 2080, and it will ignore other AD Site GCs i.e. GC3, GC4, GC7 and GC8.

Picture 3

Picture 3A

Scenario 4:

This scenario may be a little odd and may not usually happen as there is no AD with multiple AD sites but no site link. Still, I wanted to talk about this scenario so that the logic can be clearly understood. If there are no site links for any site as in Picture 4, sites are not considered. It will only use local site DC/GC.

Picture 4

Picture 4A

Now that you’ve gone over various scenarios, you may ask, what if I hardcode the GCs that are:

In-Site but do not have a direct site link with Site A, the Exchange Site, or
there is no site link with Site A, the Exchange site,

Will exchange use the GCs?

The answer is yes. It will use GCs, because if you hard code the directory servers, DSAccess bypasses the discovery process and checks only for server suitability.

Let‘s say, I run the following command, the exchange will get updated and will log the Event ID 2080 as in Picture 5:

Get-ExchangeServer MSX | Set-Exchangeserver –identity MSX – StaticDomainControllers GC3.CONTOSO.COM, GC5.CONTOSO.COM, GC7.CONTOSO.COM – StaticGlobalCatalogs GC3.CONTOSO.COM, GC5.CONTOSO.COM, GC7.CONTOSO.COM – StaticConfigDomainController GC3.CONTOSO.COM

Picture 5

In conclusion, you can ensure service continuity and minimize service downtime by setting a proper AD site link.

Applies to

Microsoft Exchange Server 2010

Microsoft Exchange Server 2007

Microsoft Exchange Server 2003

The Tool, Office 365 Delegates is here.

2013-01-23T03:59:00Z

A new Office 365 tool developed and available to use. The tool named as O365 Delegates. Let me explain , why the tool developed and what the tool does.

Why the tool, O365 Delegates Developed ?

During the course of Office 365 Exchange related troubleshooting, You need to generate various PowerShell command to collect various data.
At times, You may feel using Powershell is not very comfortable to collect the data.
I had heard from friends that if they have a tool to perform their day to day activities in managing the mailboxes rather using remote PowerShell, it will be very useful.
Also when I was checking various Microsoft Developers forums, I could see a huge demand for a sample tool to help the Office 365 tool developers.
In Order to help, Office 365 Exchange Administrators, Office 365 Tool Developers, The O365 Delegates tool developed.

What the tool does ?

The tool can be used to:

Allow others to manage your mailbox and calendar by giving delegate permission.
Find existing distribution list members.
List delegate permission.
Remove delegate permission.
Modify delegate permission level.
Grant & Revoke “Full Mailbox” and “Send As” Permission.
Run various Office 365 PowerShell commands to retrieve user/mailbox details.
It is provisioned to get LDP dump of the on-premise user through PowerShell.

As the tool can be used to perform the task that can be done with other application and thru manual PowerShell, but with less effort, it is named as Office 365 Delegates.

What is next for the tool ?

O365 Delegates to include the followings in Version 2.0,

Customizable PowerShell commands to generate various advance reports .
Run the command for multiple users.
Perform various Set commands to manage O365 mailboxes and the list goes on.

Please feel free to contact O365 Delegates Development Team to share your suggestions and feedbacks.

The Tool’s Availability:

If you are a developer and looking for sample, you can download the complete tool from the link :

http://code.msdn.microsoft.com/vstudio/Retrieve-office-365-user-63e054ad

I have also attached O365 Delegates tool's help documentation to get complete detail on the tool.

I hope the tool is helpful.