UC Unleashed

In an article I wrote earlier this year (“Installing the Exchange 2007 prerequisites on Windows Server 2008“) at Daniel Petri’s site, I showed how to use the XML files created by the product group to quickly and painlessly install the Exchange Server 2007 prerequisites on Windows Server 2008. For the most part, those work fine. But, if you’re installing multiple CAS servers, and going to load balance them using Windows Network Load Balancing (NLB) feature, you still need to manually install the NLB feature.

This can be done by either opening Server Manager, going to Features, and installing the NLB feature, or opening a command prompt and typing

ServerManagerCmd -i NLB

Since the whole idea behind the XML files was to automate the process, this wasn’t the cleanest way of doing it. Also, one of the best ways to test Hub Transport functionality is via telnet, which isn’t installed by default in Windows Server 2008. Telnet can also be manually installed via Server Manager or

ServerManagerCmd -i telnet-client

A common implementation practice is to install the Hub Transport and Client Access roles together, and then load balance CAS, as well as some hub traffic. That being the case, why not streamline the prerequiste process to include NLB and telnet? Now you can.

Open Exchange-CAS.xml, and scroll to the bottom. Right under

<Feature Id="RPC-OVER-HTTP-proxy" />

paste the following:

<!-- Install Network Load Balancing and telnet client as mentioned at https://www.ucunleashed.com/111 -->
<Feature Id="NLB" />
<Feature Id="Telnet-Client" />

Save the file as Exchange-NLBCAS.xml. Just like the others, you can call the file via servermanagercmd.exe using

ServerManagerCmd -ip Exchange-NLBCAS.xml

to install the prerequisites. Check the original article mentioned above for more info on how to use the XML files.

Enjoy!

A while back, I wrote a series at Daniel Petri’s site about Security Configuration Wizard (SCW) and Exchange 2007. The series talks about importing the files in order for the SCW to be Exchange ‘aware’. Those files, which reside in the \scripts folder, are:

1. Exchange2007.xml
2. Exchange2007_WinSrv2008.xml
3. Exchange2007Edge.xml
4. Exchange2007Edge_WinSrv2008.xml

Since that time, Microsoft has released Windows Server 2008 SP2. The SCW files that are included with Exchange won’t install on Windows Server 2008 SP2 due to a hard coded prerequisite check.

If you’re going to import the SCW files in Windows Server 2008, open each one that ends in ‘_WinSrv2008.xml’ and look for the 2nd line – which looks like this:

<SCWKBRegistrationInfo OSMajorVersion="6" OSMinorVersion="0" ServicePackMajorVersion="1" ServicePackMinorVersion="0">

Change the ServicePackMajorVersion value to “2” instead of “1”. Save the file, and you should be able to import the file using the info in my original value. Microsoft is aware of this, and working on resolving the issue.

Anyone who’s had a new mailbox on Exchange 2007 and logged in via OWA will remember seeing a screen that asks for the language and time zone, as seen below. Once they pick those, they are then taken to their mailbox.

If all of the users in an org use the same language and are in the same time zone, we can set these settings. New users will no longer be prompted for this information, but any user can change the information by going to to Options>Regional Settings in OWA, such as shown below:

To make the change, fire up the ol’ Exchange Management Shell and type:

Set-OWAVirtualDirectory "owa (Default Web Site)" -DefaultClientLanguage <Locale ID>

Replace <Local ID> with the specific Local ID for your area. For a list of Local IDs, see Locale IDs Assigned by Microsoft. For English in the United States, the Local ID is 1033. So, for my example, I use

Set-OWAVirtualDirectory "owa (Default Web Site)" -DefaultClientLanguage 1033

Once that’s set, all new users will default to that, as well as the time zone setting on the client access server.

Get-DistributionGroup "Operations" | Add-ADPermission -User "jcahill" -AccessRights WriteProperty -Properties "Member"

Large organizations generally have a large number of distribution lists. Managing membership of those DLs can often be a time consuming tasks. In earlier versions of Exchange, you could select a manager for the DL, and optionally grant that user the right to manage membership for that list, as seen below (click thumbnails for larger version).

While that option still exists, we can now assign multiple users, and even groups, the right to manage membership. And all it takes is (surprise), a little PowerShell.

For this example, we’ll take the same DL, ‘Operations’, and grant Julie the ability to manage membership.

Get-DistributionGroup "Operations" | Add-ADPermission -User "jcahill" -AccessRights WriteProperty -Properties "Member"

But Pat, you say – how is this method better? Well, we can specify a group instead of a single user like this:

Get-DistributionGroup "Operations" | Add-ADPermission -User "HelpDesk" -AccessRights WriteProperty -Properties "Member"

As seen here:

This allows anyone in the HelpDesk group the ability to manage the DL.

If we need to remove Julie’s rights, we use Remove-ADPermissions like this:

Get-DistributionGroup "Operations" | Remove-ADPermissions -User 'jcahill' -AccessRights WriteProperty -Properties "Member"

As you can see, we now have the ability to grant multiple people rights to manage a distribution list.

The last thing we need to look at is generating a report as to who has rights to manage a specific DL. For that, we can use

Get-DistributionGroup 'operations' | Get-ADPermission | Where-Object {($_.AccessRights -match 'WriteProperty') -and ($_.Properties -match 'Member')} | Format-Table User,AccessRights,Properties -AutoWidth

Which produces output such as:

Hopefully, this tip will cut down on calls to the Help Desk, and allow admins to focus on more pressing matters.

Recently, someone on a distribution list asked for a method for users to ‘agree’ to a disclaimer before being able to logon to OWA. One of the suggestions was to just append extra info to the logon page, the way that Microsoft Corporate does. Click the images below for a screenshot of Microsoft’s OWA Exchange 2007 and 2010 logon pages.

As you can see below the fields for user credentials, Microsoft has added some helpful text and links. Thanks to Ross Smith IV, I’ve gone through the way Microsoft does it, cleaned up a little, and now I’m gonna show you how easy it is.

The method Microsoft employs is to just use an ASP include to include the contents of a text file. That text file can contain any HTML code you’d like to apped to the logon screen. For the sake of example, I’m going to use the same text that Microsoft uses. Let’s get started.

1. On your Client Access Server, create a text file called disclaimer.inc in the \Program Files\Microsoft\Exchange Server\ClientAccess\Owa\Auth folder of your Exchange installation, and insert any additional code/text you want to include on your logon screen.
2. Backup \Program Files\Microsoft\Exchange Server\ClientAccess\Owa\Auth\logon.aspx for safekeeping
3. Open \Program Files\Microsoft\Exchange Server\ClientAccess\Owa\Auth\logon.aspx in notepad
4. Find <table>
   right under that, insert a line with the following:
   <!– #include file=”disclaimer.inc” –>
5. Save and close the file
6. Visit the OWA logon page, and marvel at your handywork.

There is no need to restart services, reset IIS, or anything. In fact, as soon as you make changes, you can just refresh the logon screen to see the results.

The contents of the cleaned up disclaimer.inc that yields the above results looks like this:

<div style='font-size: 8pt;'>To protect against unauthorized access, your OWA session will automatically time out after a period of inactivity. <b>If your session ends, refresh your browser and log on again.</b>
<hr />
<b>For best OWA performance, click the link that corresponds to your Exchange server:</b>
<br /><br />
<a href="/">Europe </a>
<strong><a href="/">Redmond </a></strong>
<a href="/">Sao Paulo </a>
<a href="/">Singapore </a>
<a href="/">Exchange Dogfood </a>
<a href="/">Windeploy </a>
<a href="/">WinSE </a>
<hr />
<b>Having Trouble Logging On?</b> Please contact the <a href="/">Microsoft IT Global Helpdesk</a>
<hr />
Want to find more information on OWA? Need full access to Microsoft's corporate network or alternative ways to access e-mail from Outlook or a Windows Mobile device?<br />
<a href="/">The Remote Connectivity Options extranet site gets you started.</a></div>

A couple of notes:

The Microsoft version, if you view the source of their OWA page, isn’t quite as clean as this example. I spent some time cleaning things up and removing any unecessary code so that it’s not only more compliant, but easier for the non-HTML coder to understand.

This method is completely unsupported by Microsoft. Don’t go crying to them when it doesn’t work, or blows out your OWA logon page. You made a backup of logon.aspx for a reason.

This change may get overwritten by any hotfix, rollup, and/or service pack that overwrites the logon.aspx page. So you may need to reapply the change to the logon.aspx file after updating.