As you can see, by default, it asks you for Domain\User name.  By going into the listener authentication options, you can specify the default domain that should be specified if the user does not specify a domain.  Without specifying this, if the user were to only enter their user name, authentication would fail as it is not passing the domain back to Exchange. By going into the properties of your OWA listener, you will see an Authentication tab.

Because we will be utilizing RSA, we will choose RSA as the method of Authentication utilizing Forms Based.  Because Exchange isn’t set to also authenticate to RSA (only ISA), we will need to collect additional information in the form.  This allows a user to also enter their AD credentials so after ISA authenticates a user, ISA can still pass back the AD credentials back to Exchange as the Authentication Delegation mechanism using Basic.  Selecting to Collect dditional delegation credentials in the form allows you to utilize either Basic, NTLM, or Negotiate as an Authentication Delegation mechanism.

By clicking on Advanced, we can see the section in which we can configure the domain to automatically pass back to Exchange during the Authentication Delegation.  Again, a user authenticates from a browser to a web listener and from there, ISA then takes certain information about the user and passes that back to Exchange which is the Authentication Delegation piece.

But, as you can see, the Domain name piece is greyed out.  But if you look at the authentication form for ISA when RSA is enabled, you can see it doesn’t ask for the Domain Name.

Now because of this, if a user doesn’t specify to use a different user name which does allow you to enter a domain\username, the authentication delegation piece will fail as the basic authentication mechanism that you will set on Exchange will want a domain\username passed back.  So if we can’t set this in ISA, how do we set it?  Well, we can actually configure IIS to automatically assume a specific domain to be used if no domain is specified.  While IIS6 and IIS7 are very much different, you can actually utilize the Exchange Management Console to set this option which will stamp IIS appropriately (both IIS6 and IIS7.)

The default authentication option for OWA on a CAS is to use Forms Based Authentication and require a user to specify their domain.

If you specify the following option, choose your domain, and click Apply, it will stamp IIS to assume the specified domain name.  A user can still specify their domain or not specify it and both will work when authenticating.  This should hopefully make you realize that if ISA relays authentication back to IIS on the CAS, that it won’t matter anymore if the domain is specified or not.

But because our ISA Authentication Delegation for our OWA rule will utilize Basic Authentication, we now want to specify Basic Authentication within Exchange for OWA.  But don’t worry, even if you change it from the previous setting of Forms Based Authentication with the assumed domain, IIS will still stay stamped properly. So go ahead and choose Basic.  You will be prompted to do an IISReset -Noforce.  Go ahead and do it after choosing Basic.

So back over to ISA, if we go into our Outlook Rule, we can see the Authentication Delegation set to Basic which it will need to be since that’s what the Authentication option is set to for OWA on our CAS.

So taking everything into account what we did above, what happens is the user authenticates to ISA utilizing a form and specifies their username without the domain, RSA key, and password for their username.  When they click Log On to authenticate, ISA will authenticate the user with RSA, and when that passes, ISA will utilize basic authentication due to the authentication delegation being set to basic to pass the username and password they specified (with no domain) back to OWA. Because IIS is stamped to automatically utilize the domain even if it wasn’t specified, authentication will work and the user will be logged into OWA.

In Exchange 2007, when you did a Move-Mailbox to another forest, that cmdlet would be doing some checks against your target environment to see if this user exists.  What’s the algorithm you ask?  IT’S A SECRET!  No really, it is.  It’s not really documented anywhere.  But thanks to Dmitri Gavrilov from Microsoft, the algorithm is:

• Match on objectSID – First try masterAccountSID then try objectSID and sidHistory
• Match on source LegacyExchangeDN – look for an x500:LegacyExchangeDN in target directory
• Match proxyaddresses – look for any smtp addresses in the proxyaddresses attribute that exist in the source proxyaddresses attribute

As you can see, there’s a lot of methods in which you can use.  Some may consider this bad and some may consider it good.  For Exchange 2010, Microsoft wanted to simplify the lookup process.  So instead of searching the target forest for any of the above attributes, New-MoveRequest will look for only one attribute only; msExchMailboxGuid.  Unlike Exchange 2007, the entire process for Exchange 2010 and exactly how you do this with Exchange 2010 will be fully documented. I consider this to be excellent news!

Some organizations will want to utilize ILM to bring over mail disabled users into the target forest so that New-MoveRequest will find the mail disabled user and use mail disabled user to associate a linked mailbox.  In this case, you will also want to bring over the msExchMasterAccountSid attribute which is required for linked mailboxes.

Thanks to Ian Lui from Microsoft, he provided the recommended attributes for bringing over a mail user:

• altRecipient
• deliverAndRedirect
• mail
• mailNickname
• msExchMailboxGUID
• proxyAddresses (in addition to sync source mailbox proxyAddresses, synchronized legacyExchangeDN of the source mailbox as X500 address in the ProxyAddresses attribute of the target mail user. The logic is the same when the target object is a contact.)
• publicDelegates
• msExchHideFromAddressLists
• msExchMasterAccountSid  (needed for linked mailbox)
• msExchRecipientDisplayType  (Assume the source mailbox is a user mailbox; for linked mailbox, value is equivalent to *unsigned* 0xC0000006; for regular mailbox, value is equivalent to *unsigned* 0×80000006)
• msExchRecipientTypeDetails (MailUser = 0×80,    // 128)
  TargetAddress (synchronize the PrimarySMTPAddress of the source mailbox as the TargetAddress of the target mail user. The logic is the same when the target object is a contact.)
• SAMAccountName
• userAccountControl (Disabled User Account – ACCOUNTDISABLE | NORMAL_ACCOUNT; 0×202)

You can also bring over any other attributes such as givenName, SN, etc at your discretion.

Now keep in mind, that if you are going to be migrating with a tool such as ADMT, QMM, etc. you will want to make sure the tool brings over the above attributes so when you do a New-MoveRequest, it will successfully find the target user and associate the mailbox with that migrated user.  But if you are in a resource forest scenario, that’s where you’d want to bring the user over as a mail disabled account with the msExchMasterAccountSid attribute as noted above.

Now what about companies that don’t have ILM and aren’t going to be using ADMT either?  Well, Move-Mailbox would create the mail disabled user if it found no user in the target forest with the appropriate attributes.  New-MoveRequest will NOT do this.  One reason is Microsoft wanted to reduce the complexity with Move-Mailbox.  They wanted to simplify the attribute that is used, the algorithm, and wanted to separate the AD provisioning task to another process.  Because of this, Microsoft is working on another separate tool/script that will provide the provisioning process for this exact task which reduces replication delay with the Move-Mailbox among other things.

At first, I was skeptical about all this.  Why remove functionality that was built-into the Move-Mailbox cmdlet already?  After taking an objective look at the reasoning of how complex Move-Mailbox was across forests before, and why simplifying the attribute used as well as separating AD provisioning to Exchange provisioning helps simplify the cross-forest mailbox moves and possible failures due to replication delay if you’re using the cmdlet to create mail disabled user accounts, you will understand the reasoning behind this.

Microsoft has yet to release the actual documentation on this or the script, but I wanted to give people a heads up on what’s to come.  I will update this post as those things get released.  A big thanks goes out to Dmitri Gavrilov and Ian Lui for providing a lot of the information that you see above.

If you look at the OCS R1 requirements for deploying an Enterprise Pool, it tells you the following:

• If you are using a 32-bit version of SQL Server, log on to your Office Communications Server Back-end Database server as a member of the Domain Admins group.
• If you are using a 64-bit version of SQL Server, create the pool by using a computer with a 32-bit processor, such as the computer that you plan to use as the Front End Server. Log on to the 32-bit processor computer as a member of RTCUniversalServerAdmins and Domain Admins group and with user rights to create and modify SQL Server databases.

If you look at the OCS R2 requirements for deploying an Enterprise Pool, it tells you the following:

• If you are using a 64-bit version of SQL Server, log on to your Office Communications Server Back-end Database as a member of RTCUniversalServerAdmins and DomainAdmins group.
• If you are using a 32-bit version of SQL Server, create the pool by using the computer that you plan to use as the Front End Server. Log on to this computer as a member of RTCUniversalServerAdmins and Domain Admins group and with user rights to create and modify SQL Server databases.

As you can see, it’s a complete 180 between R1 and R2.  To make it easier to digest, here’s an easier format to see what you should do:

OCS R1 with SQL 32-bit – Create Pool on SQL
OCS R1 with SQL 64-bit – Create pool on OCS FE

OCS R2 with SQL 32-bit – Create Pool on OCS FE
OCS R2 with SQL 64-bit – Create Pool on SQL

The reason why it’s a complete 180 is because Microsoft wants you to run the installer on the native platform of the installer.  OCS R1 is 32-bit so you always want to run the installer on a 32-bit machine.  OCS R2 is 64-bit so you always want to run the installer on a 64-bit machine.

But the million dollar question is, is it really necessary to run it from the Backend?  Does that mean you have to insert your OCS CD, install .Net Framework, Visual C++, etc….  Well, you could, but you  can use LCSCMD to configure your pool instead.  LCSCMD is on your CD and you can just open a cmd prompt, navigate to your cd-rom, and run the LCSCMD command with the appropriate settings to configure your pool without needing to install at the tools the installer GUI would require.  LCSCMD would also bypass the requirement from running the installer on the same processor platform (x86/x64.) You can refer to the following article here for information on how to use LCSCMD to create an Enterprise Pool.

But, that doesn’t really explain why it is recommended running it on the Backend. After talking with Ken Alverson from Microsoft about this, I learned a few things.  The reason they recommend to create the pool on the SQL Server is to minimize the possibility of firewall/permissions from interfering.  The Create Pool requires access to both SQL as well as WMI.  You can technically open up all the ports to SQL as well as WMI and run Configure Your Pool from your OCS Server.  This is what I did but instead of opening it completely, I  ran Network Monitor to determine what ports to open.  You could also disable your Windows Firewall on your SQL Server to ensure access to your SQL Server.  Never disable the firewall service on Server 2008 as this disrupts proper communication.  Either turn the firewall off or go into the advanced firewall in the administrative tools and open everything up.

So in short, you have the following options with OCS R2:

1. Turn off firewall on SQL (don’t disable firewall service) and install from OCS Server (lowers security but easiest to do.)  After the pool is created, you can re-enable your firewall as long as you follow the OCS documentation (installation guide for Enterprise Edition) and open the necessary ports.)
2. Allow SQL Ports and WMI to traverse SQL Firewall (more secure than #1 but less easy to do)
3. Run Create Pool from SQL Server via the GUI Installer (more secure than #1 and #2 but not an option I like due to it installing GUI prerequisites)
4. Run Create Pool from LCSCMD via the CD which will install a SQL prerequisite I believe (most secure option but requires knowledge of the LCSCMD command.)  You can refer to the following article here for information on how to use LCSCMD to create an Enterprise Pool.

I would appreciate if readers can make a quick comment on what method you use.

http://knicksmith.blogspot.com/2007/03/exchange-2007-and-shared-mailboxes.html

http://blogs.technet.com/msukucc/archive/2009/02/23/shared-mailboxes.aspx

As you can see, these articles including adding SendAs and/or FullAccess.  But what if you don’t want to provide FullAccess and/or SendAs and just want some basic permissions?  This is where we ran into depending on how you create the shared mailbox.  We were giving Editor+ permssions on a calendar for another user.  This would allow us to create/edit/etc.  You can see specifically what it allows by looking at the screenshot below.

So let’s say we have a shared mailbox called Aaron Tiensivu.  Yes, I’m sure many of you recognize his name from his blog here.  He’s a coworker of mine so I’m using him as an example.   I am going to open his calendar from my Outlook client and try to modify his calendar.  In order to do this, we need the following permissions:

This allows us me to open the shared mailbox’s calendar by going to File > Open > Other User’s Folder… and choosing the following options:

Again, in the case of my article, just think of Aaron Tiensivu as a shared mailbox here. :)

So I open the mailbox Aaron Tiensivu and verify that his calendar opens.

The Problem: The problem though, is that when you try to create an calendar item, you hear an error beep but no error shows up and you aren’t able to create/modify/etc. to the shared mailbox’s calendar.  Turning up Outlook Logging doesn’t reveal any pertinent information.  I did find two workarounds though which I don’t really care for and a third workaround which may or may not be considered a workaround to some.

Workaround 1:  The first workaround was by giving FullAccess Permissions on Aaron Tiensivu’s Shared Mailbox to Elan Shudnow either via EMC or EMS.  You can find out how to do that here.

Workaround 2:  The second workaround is to convert the shared mailbox to a user mailbox and start using the shared mailbox concept utilizing a user mailbox (which enables the AD account) using the following command:

Set-Mailbox -Identity “Aaron Tiensivu” -Type User

Now the interesting thing is that this only happens when you create a shared mailbox, not convert it.  What I mean by this, is this when you create a shared mailbox using the following PowerShell command, the issue occurs:

new-Mailbox -alias ATiensivu -name “Aaron Tiensivu” -database “Mailbox Database” -org Users -shared -UserPrincipalName aarontiensivu@example.com

What I noticed is that when you create a brand new user mailbox (not shared) using either the Exchange Management Console or the Exchange Management Shell, all the above delegation that previously failed with a brand new shared mailbox works as intended.  And even when we convert the user mailbox to a shared mailbox, delegate access works as intended as long as it was first created as a user mailbox instead of a shared mailbox.  It’s almost as if there’s some issue when you create a shared mailbox but it’s fine when creating a regular user mailbox and converting it to a shared mailbox.

A fellow MVP, Glen Scales, had recommended I try using a MAPI Editor and/or pfdavadmin to check the local freebusy folder in the NON_IPM_Subtree to see whether the correct permissions are being applied.  Glen did point out that the Outlook client should be taking care of this permission.  Unfortunately because we see that Shared Mailboxes work after converting them, our team moved onto other things for the remainder of the day due to a tight schedule.  If I do find time, I’ll try creating a shared mailbox from scratch and check this out and update this post.

Now of course, you may not encounter this issue as I have.  As IT people, we all know that sometimes things work in one environment and not the other.  So if you do happen to have this issue and find yourself reading this blog entry, please submit a comment with your findings/information.

The script will sort all the mailboxes by size and take 40% of the largest mailboxes and move them to a specified database and take the remaining 60% and move them to the other database.

If you don’t want to specify the exact database name and just want PowerShell to use part of the name you specify to find a matching database, you can change the part where it states {$_.Name -eq $sourceDB} to have -like instead of -eq. Do the same for the following two pieces of code: {$_.Name -eq $targetDBLarge} and {$_.Name -eq $targetDBSmall}. -eq needs the exact match for the database name and -like basically takes the database name and puts wild cards around it so it’s more like *databaseyouspecify* and then finds a matching database that is like the name you specified.

Important: I added -whatif switches to the move-mailbox commands below to be extra safe. To actually move the mailboxes, you’ll need to remove the -whatif.  And as always, MAKE SURE YOU TEST THIS IN LAB BEFORE RUNNING IT IN PRODUCTION AND HAVE A GOOD BACKUP UP AD/EXCHANGE/ETC AS WELL!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$sourceDB = "Specify your Source Database Here"
$targetDBLarge = "Specify your larger database in which 40% of the largest mailboxes will be moved to"
$targetDBSmall = "Specify your smaller database in which the remaining 60% of the smaller mailboxes will be moved to"
 
############################################
####### Don't modify below this line #######
############################################
 
$a = Get-MailboxStatistics -Database $(Get-Mailboxdatabase | Where-Object {$_.Name -eq $sourceDB}) | where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|ExOleDbSystemMailbox)'} | Sort-Object Totalitemsize
 
$rounded = [math]::round($a.count * .4)
$first = $rounded
$last = $a.count - $first
 
$a | Select-object -First $first | Move-Mailbox -TargetDatabase $(Get-Mailboxdatabase | Where-Object {$_.Name -eq $targetDBLarge}) -whatif
$a | Select-object -Last $last | Move-Mailbox -TargetDatabase $(Get-Mailboxdatabase | Where-Object {$_.Name -eq $targetDBSmall}) -whatif

Scriptlet 1

Find out all users who live on a specific mailbox without having to type the entire mailbox database name:

1

get-mailbox -database $(get-mailboxdatabase | where-object {$_.name -like "*Database1*"}) | Format-Table Name,Database -wrap -autosize

Scriptlet 2

Get statistics on a specific user without knowing the entire name or if you’d want to find out statistics on all users who have the first name John or last name Doe:

1

Get-MailboxStatistics -server serverhere | Where-Object {$_.DisplayName -like "*MailboxUserName*"} | Format-Table DisplayName,ItemCount,TotalItemSize

Scriptlet 3

When you are in an environment with multiple Mailbox Servers, it may be annoying to find what disconnected mailbox lives on which server since the Exchange Management Console will only connect to one server at a time and when connected, it’ll only show disconnected mailboxes for that specific server.  This scriptlet will cycle through all mailbox servers and report back all disconnected mailbox servers and which disconnected mailbox lives on which mailbox server.

1
2
3
4

$mbx = Get-ExchangeServer | Where-Object {$_.IsMailboxserver -eq $true}
foreach ($server in $mbx) {
	Get-Mailboxstatistics -Server $Server | Where-Object { $_.DisconnectDate -ne $null } | Format-Table DisplayName,ItemCount,OriginatingServer -wrap
}

Scriptlet 4

Based on a CSV file, export users contacts that were created after a certain start date to a PST file.  A copy of how the CSV should be formatted is located here.  While the CSV contains multiple columns, the script only utilizes the Account Name column by default.  If you want to modify what columns it uses, you can change the line below that starts with $AdName =.  After the script pulls the name in the Account Name field, it finds the mailbox using the Get-Mailbox command with the name that was specified in the Account Name field.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

$file = "pstusers.csv"
$PSTLocation = "C:\PSTs"
$StartDate = "03/20/2009"
 
############################################
####### Don't modify below this line #######
############################################
$erroractionpreference = "SilentlyContinue"
if (!(Test-Path -path $PSTLocation)) {
	Write-Host "Creating the Directory $PSTLocation" -ForegroundColor Yellow
	New-Item -ItemType "Directory" -Path $PSTlocation
}
if (Test-Path $file) {
	$excel = Import-CSV $file
	foreach ($line in $excel) {
		$AdName = $line."Account Name"
		$Mailbox = Get-Mailbox $AdName
		if ($Mailbox) {
			Write-Host "$AdName is being exported to $PSTLocation"
			$Mailbox | Export-Mailbox -PSTFolderPath $PSTLocation -StartDate $StartDate -ExcludeFolders "\Inbox","\Deleted Items","\Drafts","\Junk E-mail","\Outbox","\Sent Items","\Journal","\Calendar","\Notes","\Tasks"
		}
		else { Write-Warning "$ADName Mailbox Does not Exist" }
	}
}
else {
	Write-Warning "The file $file does not exist"
}

Scriptlet 5

If you are familiar with Quest Notes Migrator for Exchange, you may have had the chance to migrate data to a PST file.  What you will see, is that the PST gets migrated with the Display Name of the user.  For example, we if migrated the Notes mailbox of Elan Shudnow to a PST, the PST file name would be Elan Shudnow.PST. A lot of people won’t want to migrate the PST directly from Quest NME to a user’s home share because that user’s home share may be located in a remote site and opening a PST file across a network isn’t really a good idea; especially over long distances.

So I wrote a script so you can migrate all the PST files locally and then it’ll check the Display Name portion of the PST file and use that display name to find a matching user in AD and then find their home directory and then copy that PST file to that home share.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

# Set Location to where the PST files are started
Set-Location "E:\"
 
$pstData = Get-ChildItem -recurse | Where-Object {$_.Name -like "*.pst"}
 
function Get-HomeDirectory ($displayName) {
	$ads = New-Object System.DirectoryServices.DirectorySearcher([ADSI]'')
	$ads.filter = "(&(objectClass=Person)(displayName=$displayName))"
	$s = $ads.FindOne()
	return $s.GetDirectoryEntry().homeDirectory
}
 
foreach ($pstUser in $pstData) {
	$PSTName = $pstUser.Name
	$PSTDisplayName = $pstUser.Name.split(".")[0]
	$PSTDisplayName = $PSTDisplayName.split("-")[0]
	$Path = $PSTUser.DirectoryName + "\" + $PSTUser.Name
	$Directory = Get-HomeDirectory $PSTDisplayName
	Copy-Item $Path $Directory
}

Management History

Exchange 2003 provided management with the Exchange System Manager. Exchange 2007 provided management with the Exchange Management Console (EMC) and the Exchange Management Shell (EMS).  You were limited as to what you could do based on what Exchange Management Group you were in.

Exchange 2003 administration groups consisted of:

• Exchange Full Administrator
• Exchange Administrator
• Exchange View Only Administrator

Exchange 2007 administration groups consisted of:

• Exchange Organization Administrators
• Exchange Recipient Administrators
• Exchange View-Only Administrators
• Exchange Public Folder Administrators (New in Exchange Server 2007 Service Pack 1)

Exchange 2010 Management/Permissions Overview

Exchange 2010 provides a much more comprehensive method for allowing granular control over what users have control of what functions. This functionality is provided by a new Role Based Access Control (RBAC) authorization system.  The goal of this system is to provide an easy way to delegate and customize control by granting operations based on role or job function.  For example, you can provide your helpdesk certain abilities to perform the job functions they need in a more granular fashion.

The benefit of RBAC is obvious.  Many Exchange Administrators found themselves in situations where they needed to provide less privileged administrators additional privileges but did not want to add them into an administration group that gave too much control as this would not conform to principle of least privilege.  With RBAC, we can provide this less privileged administrator with the control they need without needing to place this administrator into a group that would provide this administrator with too many unneeded privileges.

The new RBAC model works in all Exchange Management applications; Exchange Management Console, Exchange Management Shell, and the new Exchange Control Panel (ECP). The ECP is a new Management Tool provided in Exchange 2010.  It’s a web based management console that is targeted towards the end user and administrators alike.  It’ll allow end users to do simple things such as modify their phone number, if allowed of course.

Because Exchange 2010 utilized PowerShell 2.0, Exchange now has the ability to take advantage of PowerShell Remoting which allows you to remotely manage your Exchange systems; if that didn’t already seem obvious by the name PowerShell Remoting.

Role Based Access Control (RBAC)

As stated, RBAC is the new authorization system that provides an easy way to delegate and customize control by granting operations based on role or job function.  With RBAC, there are for main important things to note:

• Management Role – Exchange Security Group that you create.  Help Desk Tier 1, Help Desk Tier 2, Admin Tier 1, Admin Tier 2, etc…
• Management Role Entries – What each Management Role has access to.  What cmdlets can these Management Roles use?
• Management Role Assignments – What Security Group and/or user is a Management Role assigned to?
• Management Role Scopes – What target of users, OUs, servers, filtered objects, etc. do these management roles have access to adminster?

As you can see, this system is really flexible and is definitely welcome. There’s already quite a bit out there on the Technet Library on how this all works, so instead of regurgitating it, I encourage you to go check it out here.

1. Database Availability Groups – Database Availability Groups combine CCR and SCR functionality to provide a single solution for both scenarios.  What happens here is that you install a DAG member and it behind the scenes installs Failover Clustering making the High Availability deployment more intuitive for the administrator.  There was one scenario we ran into here where we had two source CCR Clusters wanting to replicate to the same target SCR Standby.  The problem here is that when you recoverCMS on the SCR Standby, the replication fails with the other source CCR that was still working becuase the target SCR server can only ever have 1 CMS.  DAGs fix that issue.
2. Outlook Web Access Features – There are quite a few new features with OWA.  Some features I really like are:
   • Side-by-side comparison of calendars
   • Ability to attach messages to messages
   • Integration with Communicator including presence, chat, and a contact list
   • Conversation View
   • Support for multiple browsers such as Firefox and Safari
3.  Unified Messaging Features – There are quite a few new features with UM.  Some features I really like are:
   • Message Waiting Indicator
   • Voicemail Preview – This is essentially a speech to text that will display the text in your e-mail message to get a preview of what the voice mail includes
   • Personal auto attendants
   • Protected Voice Mail – Ability to track and restrict where voice mails can go
4. Store Functionality  – There are a ton of new features for UM.  Some important things to note:
   • No more Storage Groups
   • Mailboxes are no longer connected to the server object in which the schema has been flattened to allow for this
   • I/O Improvements including JBOD support and better support for SATA disks
   • Being able to run on cheap disks (SATA) and have a backupless organization by having multiple copies stored on DAG members.
5. Administration  – There are a ton of additions/enhancements to administration.  Some important things to note:
   • Role Based Access Control (RBAC) – Allows you to create granular permissions on custom groups that you create. This essentially replaces the administration model in Exchange 2007.  For example, if you want a help desk group that has access to specific pieces of functionality within Exchange, you can do so.
   • Exchange Control Panel – Ties into RBAC and shows/hides features you are not given access to.
   • Audit Logging
6. Other
   • Multi-Mailbox Search
   • Text Messaging Integration (SMS)
   • Moderation and approval of distribution group submissions
   • Mail Tips – Will notify an Outlook user of an impeding error before it happens so the user doesn’t get a confusing NDR.  For example, if your message size limit is 10MB and the user tries sending a 15MB message, Outlook will notify the user before the user tries to send out the e-mail saving Exchange resources and making the failure experience more intuitive for the end user.

There’s definitely quite a bit more in which you can start reading here.  I’ll mostly update this post here and there so be sure to check back.  You can definitely expect me to start creating new content around Exchange 2010 in the near future.

In this Part, I will go over the installation of our Group Chat Server and Administrative Tools.

Part 1

Part 2

Group Chat OCS 2007 R2 Server Installation

When installing OCS R2 Group Chat  and running the setup executable, you will be asked to install several pieces of software to prepare the environment.

You will be asked to install the Microsoft Visual C++ 2008 Redistributable. Click Yes to Continue.

You will then be asked to install the Microsoft .NET Framework 3.5. Click Yes to Continue.

You will then be asked to install the Microsoft Unified Communications Managed API 2.0 Core Redist 64-bit version.  Click Yes to Continue.

Once Microsoft Unified Communications Managed API 2.0 , you will be presented with the Welcome screen which will begin the installation process.  Click Next to Continue.

The next screen is the licensing screen.  Make sure you fully read the entire agreement!  Once you have done so (and I know you will, right?) Click Next to Continue.

Enter your Username and Company information. Click Next to Continue.

Enter the installation path you want the binaries installed to. Click Next to Continue.

When the feature screen appears, you have 2 choices which are both selected at the same time.  Keep in mind, that you must disable one of the options.  You cannot have both the Chat Server and the Compliance Server collocated on the same box.  Make sure the Chat Server is selected and the Compliance Server is not selected.  We will be installing the Compliance Service in the next Part.  Click Next to Continue.

Confirm your installation.  Click Next to Continue.

Installation is ready to proceed.  Click Next to Continue.

During the installation, you will see the Server Configuration wizard appear.  Because we chose the Chat Server to be installed, you will see three Server/Service roles being installed:

• Lookup Server
• Channel Server
• Web Service

Click Next to Continue.

We now want to specify what SQL Instance we want to use.  One thing to keep in mind is to take a look at the collocation technet article to see how databases can be collocated on the same SQL box.  You can find this article here.  You can see the following databases can be on the same SQL Box:

• Archiving database
• Monitoring database
• Group Chat database
• Compliance database (for Group Chat)

One thing to keep in mind here, is that for each database, it requires its own instance.  In the case of Group Chat database and the Compliance Database, the Compliance Database can be a dedicated database or it can be the same database as the Group Chat database.  In Part 2, we will be using the Group Chat database as the Compliance database.

As you may recall from the OCS R2 Enterprise article series here, we’re using a SQL 2008 x64 Back End.  Make sure port 1433 is allowed inbound.  Instructions on how to do this are documented in that article series.

Specify your Server\Instance and Database.  As stated, I’m just using the default instance for everything since it’s a lab.  Specify your settings accordingly.  Click Next to Continue.

The next screen will just notify you that your databases are empty and that it will create the schema information.  Click Next to Continue.

We will want to specify a Super User.  It’s pretty obvious what this user is.  It’s essentially the Administrator account in AD.  The first time you create AD, you will log in with the Administrator account and start creating other Administrator accounts from there.  The Super User is the same thing.  Because this is a lab, I am using the Administrator account to manage everything.  So in the User name field, I specified my Administrator account and clicked Add. Click Next to Continue.

Specify the name of your pool and the MTLS Certificate that will be used by your Group Chat Server.  You will need to create this certificate beforehand by using LCSCMD, CertSRV website for an internal CA, or using the OCS Administrative Tools.  Click Next to Continue.

Remember I said the Lookup Service is the one service that will be utilized across all Group Chat Servers and that it also needs to be SIP Enabled?  Well now is the time to enter in the Lookup Service credentials and SIP information. Click Next to Continue.

Do the same for your Channel Service. Click Next to Continue.

On the next screen, we’ll be asked for our Compliance settings.  Because this is the first Group Chat Server and we have not yet deployed our Compliance Server, we’ll leave these settings blank and re-visit the configuration later.  Click Next to Continue.

Specify the  directory that will be used for uploads to the Web Service.  You will want to use a UNC path, especially if you’re using multiple Group Chat Servers.  I created a shared folder called WebService.  You will need to ensure your Channel Service has read/write to this share (both Share and NTFS permissions.) Click Next to Continue.

Review your settings. Click Finish to Continue. When finished installing, Click Close.

You will want to ensure that Anonymous Authentication is enabled in IIS on your MGCWebService directory in your Default Web Site.  After doing so, you will want to use your Channel Service account as the credentials used for Anonymous Authentication.  It doesn’t have to be the Channel Account, but just an account that has RTCComponentUniversalServices permissions because the account needs to access the file repository and Message Queuing.

Group Chat OCS 2007 R2 Administrative Tools

As most of the other client and administrative tools installations, I won’t go over the installation procedures as they’refairly straightforward.  So go ahead and install the Administrative Console.  I have installed it on our SHUD-PG1 Server which is the server we installed the Group Chat Server on.

Once installed, go to Start > Programs > Microsoft Office Communications Server R2 > Microsoft Office Communications Server R2, Group Chat Administration Tool

Once you open it, Group Chat Administration will always be set to do an Automatic Logon and use the existing signed on account.

You may have trouble getting this part to work properly.  This is my 2nd time installing and getting Group Chat to work so I’ve went through the pain to get everything to work properly and seamlessly off the bat.  The trick is, during Group Chat installation, you gave it a super user.  You’ll want this to be your Administrator account you’re using to install Group Chat and the system that you will be loading the Administration Tool.  Only a super user can load up the Administrative Tool.  So if you set your Administrator account that you log onto which is also SIP enabled as the Super User, and are logged onto that account when loading up Administrative Tool, everything will just work.

If Automatic Configuration does not work, you can set the Account to Manual Configuration and manually configure the account to use for log-on, DC to use, etc…

You can now create new Chat Rooms on the left, add new Super Users, Chat Room Managers, etc..

Summary

Well folks, that is all for Part 2 of this article as well as the 2 part article series.  Hopefully it helps you plan and deploy Group Chat.