|
|
|
|
|
|
|
|
> MMCUG Blogs
|
|
5/17/2009
As consultants, we are constantly using remote desktop to connect to servers and workstations in a remote fashion. If the boxes we're trying to connect to are Microsoft servers or workstations, then using Microsoft's Remote Desktop is a breeze. (In Windows 2000 days the feature was called Terminal Services in Remote Administration mode.)
My problem with the RDP (Remote Desktop Protocol) process was connecting to a remote machine if the server was deployed without having the little checkbox checked next to the option Enable Remote Desktop on this Computer. See this dialog box below – this is from looking at the Properties of my server and choosing the Remote tab.
So, if a server is deployed like this, you can't remotely connect to it via the RDP protocol with the remote desktop application. Now, you can physically connect to the server to enable the checkbox option, but sometimes that's inconvenient or impossible.
Attempting to connect to a machine using Microsoft's remote desktop connection when the remote feature has been left off (by default the remote desktop box is not checked) reveals this error message:
So, in this article I'll show you how to remotely enable this checkbox. Once the box has been "checked" so-to-speak, then you can remotely connect using Microsoft's remote desktop application.
The solution is to use a different machine to connect to the "un-touchable" machine's registry to "enable" this checkbox. Let's say I'm sitting at my XP Pro workstation and I need to remotely administer the Windows Server 2003 machine at 10.0.0.10. This is the scenario.
First, I need to open the registry editor on my local workstation. So I click Start and type REGEDIT on the run line. I now need to select the Connect Network Registry option from the File menu like you see me doing below.
This menu opens the Select Computer search dialog box. Now, I need to either browse Active Directory to locate the remote server, or simply type its name in the textbox labeled Enter the object name to select.
After clicking OK, a node will be displayed in the Registry Editor tool for this remote server I'm trying to connect to.
Now I browse to the location listed below from the node just added to the Editor:
HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server
From the Terminal Server key, I look for the REG_DWORD value named fDenyTSConnection.
I Double-click on that value to open the Edit DWORD Value box and change the data from a 1 to a 0. The default value of 1 means that Terminal Services is in fact being denied – hence the reason I couldn't connect. Changing the value to a 0 means to NOT deny Terminal Services.
Choosing OK will complete this process of not denying Terminal Services which in effect "checks the box" I spoke of earlier.
But, I'm not done yet. One last step to perform to complete this process is I need to reboot the server I'm trying to connect to. Obviously this cannot be performed during critical times the server is needed. But, when the time is right I can remotely reboot the box using Microsoft's Shutdown command. This command will – when switches are used correctly – will allow me to remotely reboot the server. When the server comes back up again, I can now successfully connect to this server.
The command to remotely reboot the server is:
Shutdown –m \\server_name –r
I enter the correct server name in place of my "server_name" text, or I can enter it's IP address instead. If I enter it's name, I will not enter it's fully-qualified domain name – just its NetBIOS name. The –r switch tells the tool to restart the server instead of truly shutting it down. This switch is critical for obvious reasons. There are tons of options I can use with this command. One nice switch is the switch to have the shutdown process start in a value of time. The –t xxx switch will allow me to schedule the shutdown in xxx number of seconds. Usually a value of 30 for 30 seconds works well.
Once the server is back up and running, I'll have no problem using Microsoft's remote desktop to access the server. Of course, I must have proper permissions to do so.
One last observation I've noticed using this handy trick – the process I've described here works exactly as described when the server I'm trying to remotely connect to has never had its remote connectivity options enabled – such as on a brand-new machine. A reboot is required to fully complete this process. However, once the server has been restarted, you can always remotely connect to the server using REGEDIT in the same manner I've described here to remotely change the fDenyTSConnection option back to a value of 1. This will once again render the server so no one can remotely connect using remote desktop software. Once this value is set back to a 1 – and even when you later come back and change the value again back to a 0 from the 1 value – you will no longer have to reboot the server. It's only the very first time a change is made to the registry keys will you have to reboot the server. Therefore, after the first time you can easily switch back and forth with the 0 or 1 values to turn on or off the remote connectivity and not have to affect the operation of the server.
Mark Myers
Senior Consultant
4/22/2009
Recently, I had the need to generate some pretty complex email test data for a lab environment for Quest Archive Manager. I needed to create a lot of messages of variable length and some that had attachments. This was to create messages that would fit into a stripping/stubbing policy, as well as creating messages by which I could test the attachment indexing features to demonstrate to a client. I had a few requirements that I needed to meet:
- Must have the ability to send email to/from various users in the current Exchange GAL either by providing a list or randomly grabbing people from the GAL
-
Must have the ability to send different types of messages which I defined as 3 types:
- Short (small text messages limited to 1 paragraph)
- Long (large text messages such as speeches, etc).
- Messages with Attachments
- Must be able to randomly pick from the different message types and send several hundreds and potentially thousands of messages.
I spent some time searching on the web, and didn't really come across much other than some VBS and PowerShell scripts for sending SMTP messages. Unfortunately, all these really did was send the same message X number of times to the same recipient, and they weren't really even close to fulfilling my requirements.
A colleague sent me a link (http://blogs.flaphead.dns2go.com/archive/2008/11/19/send-mail-ps1-v3-2-7-november-2008.aspx) to the PowerShell script SendEmail.ps1. This was similar to the other scripts I had seen and didn't really fit the bill. However, it being written in PowerShell gave me a base to work off of.
I set about to build a wrapper for this script that would provide the requirements I needed. The first step was building a script to randomize pulling people from the GAL. That seemed easy enough:
$randsource = New-Object System.Random
$mailsources = get-mailbox -resultsize Unlimited
$sourcesize = $mailsources.length
$nextsource = $randsource.next(0,$sourcesize)
$senderSMTP = [string] $mailsources[$nextsource].PrimarySMTPAddress
This got me sender address from the GAL by looking up all the mailboxes, and then randomly selecting a user from the list. Of course, you wouldn't want to do this on a large production environment, but will work fine with my test lab. Using similar code, we get a target address:
$randtarget = New-Object System.Random
$mailtargets = get-mailbox -resultsize Unlimited
$targetsize = $mailtargets.length
$nexttarget = $randtarget.next(0,$targetsize)
$targetSMTP = [string] $mailtargets[$nexttarget].PrimarySMTPAddress
Now, I wanted to add a few checks. I put in a check to make sure that $targetSMP was not the same as $sourceSMTP. If it was, I had it go fetch another target by calling "$nexttarget = $randtarget.next(0,$targetsize)" again. Having my recipients, I now needed some content. The best way I calculated to do this was by creating 3 input CSV files with the following headers:
ShortEmail.csv
-------------------
Author,Body,Subject
LongEmail.csv
-------------------
Author,Body,Subject
AttachmentEmail.csv
-------------------------
Author,Body,Subject,Attachment
I then just populated the CSV files with content. The AttachmentEmail.csv Attachment field was pointing to some files for each email that I could use for test purposes.
I then used similar functions to randomly select a message type and a message from each file. I also inserted some code for the servername for SMTP and an exception list for users I want excluded from the list. Here is the script in total:
write-host " "
$emailcount = 1000
$excludemail = "Administrator@contoso.com%admin@contoso.com"
$mailserver = "EXCHANGE"
$shortemails = Import-Csv "C:\Scripts\work\ShortEmail.csv"
$longemails = Import-Csv "C:\Scripts\work\LongEmail.csv"
$attachemails = Import-Csv "C:\Scripts\work\AttachmentEmail.csv"
$smallsize = $shortemails.length
$largesize = $longemails.length
$attachsize = $attachemails.length
$prevsmall = 0
$prevlarge = 0
$prevattach = 0
$randsource = New-Object System.Random
$randtarget = New-Object System.Random
$randformat = New-Object System.Random
$randsmall = New-Object System.Random
$randlarge = New-Object System.Random
$randattach = New-Object System.Random
$mailsources = get-mailbox -resultsize Unlimited
$mailtargets = get-mailbox -resultsize Unlimited
$sourcesize = $mailsources.length
$targetsize = $mailtargets.length
$i=0
while ($i -le $emailcount) {
$nextsource = $randsource.next(0,$sourcesize)
$nexttarget = $randtarget.next(0,$targetsize)
while ($excludemail -match $mailsources[$nextsource].PrimarySMTPAddress) {
$nextsource = $randsource.next(0,$sourcesize)
}
$excludetarget = $excludemail + "%" + $mailsources[$nextsource].PrimarySMTPAddress
while ($excludetarget -match $mailtargets[$nexttarget].PrimarySMTPAddress) {
$nexttarget = $randtarget.next(0,$targetsize)
}
$senderSMTP = [string] $mailsources[$nextsource].PrimarySMTPAddress
$targetSMTP = [string] $mailtargets[$nexttarget].PrimarySMTPAddress
$nextformat = $randformat.next(0,3)
$mAuthor = "Nobody"
$mBody = "If you're seeing this, then something didn't get set properly."
$mSubject = "Default Null Message Subject"
$mAttachment = ""
switch ($nextformat) {
"0"
{
$nextsmall = $randsmall.next(0,$smallsize)
while ($prevsmall -match $nextsmall) {
$nextsmall = $randsmall.next(0,$smallsize)
}
$prevsmall = $nextsmall
$mAuthor = $shortemails[$nextsmall].Author
$mBody = $shortemails[$nextsmall].Body
$mSubject = $shortemails[$nextsmall].Subject
}
"1"
{
$nextlarge = $randlarge.next(0,$largesize)
while ($prevlarge -match $nextlarge) {
$nextlarge = $randlarge.next(0,$largesize)
}
$prevlarge = $nextlarge
$mAuthor = $longemails[$nextlarge].Author
$mBody = $longemails[$nextlarge].Body
$mSubject = $longemails[$nextlarge].Subject
$mBody = $mBody -replace "~","`r`n"
}
"2"
{
$nextattach = $randattach.next(0,$attachsize)
while ($prevattach -match $nextattach) {
$nextattach = $randattach.next(0,$attachsize)
}
$prevattach = $nextattach
$mAuthor = $attachemails[$nextattach].Author
$mBody = $attachemails[$nextattach].Body
$mSubject = $attachemails[$nextattach].Subject
$mAttachment = $attachemails[$nextattach].Attachment
}
}
if ($mAttachment -ne "") {
C:\Scripts\send-mail.ps1 -server $mailserver -from $senderSMTP -TO $targetSMTP -subject $mSubject -body $mBody -attachment $mAttachment –verbose
} else {
C:\Scripts\send-mail.ps1 -server $mailserver -from $senderSMTP -TO $targetSMTP -subject $mSubject -body $mBody –verbose
}
$i
$i++
}
write-host " "
PLEASE NOTE: THIS SCRIPT SHOULD BE USED IN TEST ENVIRONMENT ONLY. It will pretty much spam random users if run in production, which is bad.
Using this, I was able to create all the test data I needed quickly and easily.
Eric Gentry
Senior Consultant
Project Leadership Associates
3/31/2009This article will discuss the optional configuration of how to enable redundant networks in a Server 2008 Failover Clustering scenario for supporting log shipping. Primary to this article is Exchange 2007 CCR nodes in a cluster and the configuration of setting up the public and private networks for supporting log shipping between the two CCR nodes.
By default, the private network carries only heartbeat traffic between the CCR nodes. The public network carries the log shipping or seeding traffic. To configure the private network to also support carrying the log shipping or seeding traffic, the following procedure will need to be performed.
The private network will need to be configured for "mixed network"; this is done using the EMS. A mixed cluster network is any cluster network that is configured for both cluster (heartbeat) and client access traffic. When a mixed cluster network has been configured, Microsoft Exchange Server 2007 uses that network for log shipping. Multiple mixed networks can be specified, and if more than one network is available, Exchange 2007 randomly selects one of the networks. If the network currently in use becomes unavailable, Exchange 2007 automatically selects another available network.
Article Node Configuration
For the purposes of this article, the following specifics are helpful to know when references are made:
CCR Names –
CCR Node Names: S08-E2k7-CCR1 and S08-E2k7-CCR2
CMS Name: CCRCMS
IP Addresses –
S08-E2k7-CCR1 Public: 10.10.10.1, Private: 192.168.1.1
S08-E2k7-CCR2 Public: 10.10.10.2, Private: 192.168.1.2
CCRCMS: 10.10.10.3
Name Resolution
On the adapter being configured for continuous replication traffic, name resolution must be configured specifically for the mixed network and NIC. Likely, the check box for the "Register this connection's address in DNS" has been cleared – and this is best practice for traditional cluster configurations. However, for CCR on Server 2008, either a static DNS entry for the new continuous replication host name or entries to the nodes' HOSTS file will be necessary to provide for name resolution.
NetBIOS name resolution is also necessary on the mixed network. The private NICs will likely have this disabled, as best practice from MS dictates. However, if NetBIOS name resolution isn't enable, the mixed network configuration will not support log shipping and/or seeding. If NetBIOS is not enabled, the Network Name resource will not come online, even if you enable NetBIOS for the adapter after the resource has been created. To resolve this issue, you must remove the cluster group and resources for the continuous replication host name, enable NetBIOS for the adapter, and then perform the following procedure.
Overview of the Entire Procedure
Follow the high level summary list below to configure the CCR nodes for Continuous Replication. Detailed steps supporting this high level list are presented below the summary.
- Create a new network host and IP address to support the mixed network.
- Enable NetBIOS on both private NICs.
- Create new entries in both CCR nodes' HOSTS file to resolve new backup name with new IP address.
- Configure the private network to support mixed or client access.
- Configure Windows Server 2008 for Alias name support via a registry change.
- Execute the Enable-ContinuousReplicationHostName cmdlet on nodes.
- Check status
A new network host and IP address must be established to support mixed networks. This is discussed in section 1.3 below
ContinousReplicationHostName Concept
In Exchange Server 2007 RTM, all operations (transaction log file copying and seeding) occurs over the Public network which is the same as used by the clients to access their data. In some cases if there are a higher number of log files to be transferred it might impact client performance. From a security perspective the log files are being transferred through the Public network and to secure this process we can use encryption that increases the performance of the servers involved.
After SP1, we can use one or more networks for log shipping, like the private network responsible for carrying the heartbeat traffic. We just need to associate a new hostname and new IP address to be used by the Replication service. If we have more than one redundant network available the service will pick one randomly to use. If one redundant network becomes unavailable the other redundant network will be selected. If none of the redundant networks are available the public network will be selected. The replication service discovery service runs every 5 minutes. As soon as an available redundant network is detected the replication will start to use the redundant network instead of the public network.
Prerequisites for deploying the Continuous Replication Hostname Support in Exchange 2007 SP1
Before creating the new hostnames and new IP address resources to be used we must make sure that some points are covered, such as:
- Configure the network that will be used to replicate as a Mixed network in the Cluster Administrator. In Server 2008 this is labeled as "allow clients to connect through this network".
- Configure Windows Server 2008 to be accessed through Alias names via a registry addition.
- Configure name resolution to the new hostnames that can be done using host file entries.
Assuming our lab environment for this article, the current CCR network configuration can be seen in the first three columns of the table below. Let us assign a Continuous Replication Hostname and an IP Address for each node. Note: this IP address must be an address in the same range of the Private Network.
|
CCR Node/Host
Existing Config. |
Public IP
Existing Config. |
Private Heartbeat IP
Existing Config. |
Continuous Replication Host Name
New Config. |
Continuous Replication IP Address
New Config. |
|
S08-E2k7-CCR1 |
10.10.10.1 |
192.168.1.1 |
CCRCR01 |
192.168.1.3 |
|
S08-E2k7-CCR2 |
10.10.10.2 |
192.168.1.2 |
CCRCR02 |
192.168.1.4 |
|
CCRCMS (CMS) |
10.10.10.3 |
NA |
NA |
NA |
Configuring the Private Cluster Network
Even though the private heartbeat network will not be accessed by external clients, it must be defined as mixed – or Allow clients to connect through this network.
To make this setting:
- Open Server 2008 Failover Cluster Management MMC.
- Expand the MS cluster, expand the Networks node and open the properties of the Private network node, as shown below.
3. Enable the checkbox as shown below for Allow clients to connect through this network, as shown below.
4. Click OK to complete this process. Perform the same procedure for the other CCR node.
Configuring Name Resolution
Each CCR node will need to contact the new host name that will be created for the private network. The new host names will be the following:
For Node – S08-E2K7-CCR1 – new additional host name of S08-E2K7-CCR1BKP
For Node – S08-E2K7-CCR2 – new additional host name of S08-E2K7-CCR2BKP
The new hostnames that will be created are the ones ending in the "BKP" characters. Each CCR node must be able to perform name resolution on the new name; for example, CCR node S08-E2K7-CCR1 must be able to resolve the new hostname of S08-E2K7-CCR2BKP which will be a new hostname for the other CCR node – and vice-versa. Because the private network cannot contact outside DNS, a HOSTS file entry will need to be made on each CCR node. This is shown below. (The "CRH" abbreviation stands for Continuous Replication Hostname.)
Accessing Windows Server 2008 through an Alias Name
In Windows Server 2008 a registry key must be added in all nodes of the CMS (Clustered Mailbox Server) to allow access through the alias name - by default this behavior is blocked.
Open the registry, and expand HKEY_LOCAL_MACHINE, System, CurrentControlSet, Services, LanManserver, Parameters. Then, right click on the right side and click on New, click on Dword Value, type in DisableStrictNameChecking, define the new value as 1. The result will be shown as below.
Perform this registry addition on the other CCR node as well. Reboot both CCR nodes to make the registry change complete.
Configuring the Continuous Replication Hostname Feature
The following procedure cannot be accomplished in any GUI tool; it must be performed by the EMS. To create the two new hostnames (one for each CCR node), execute the cmdlet Enable-ContinuousReplicationHostname on each node. The general syntax is:
Enable-ContinuousReplicationHostName -Identity <CMSName> -TargetMachine <NodeName> -HostName <NetworkNameforReplication> -IPV4Address <IPv4DottedDecimalIPAddress>
The exact syntax based on my lab is described below:
On Node S08-E2K7-CCR1:
Enable-ContinuousReplicationHostName –Identity CCRCMS –TargetMachine S08-E2K7-CCR1 –Hostname S08-E2K7-CCR1BKP –IPv4Address 192.168.1.3
On Node S08-E2K7-CCR2:
Enable-ContinuousReplicationHostName –Identity CCRCMS –TargetMachine S08-E2K7-CCR2 –Hostname S08-E2K7-CCR2BKP –IPv4Address 192.168.1.4
The two cmdlets will take some time to run; after successfully executed these cmdlets, you will see a new network group inside the Failover Cluster Manager tool. The two new groups will be called S08-E2K7-CCR1BKP_group and S08-E2K7-CCR2BKP_group. The two IP addresses used in the previous cmdlet will be associated with the two new groups as shown in the example figure below taken from an isolated lab environment. See the figure below for an example of the new objects in the Failover Cluster Management tool.
Check Status
To check the status of the new host names, execute the cmdlet Get-ClusteredMailboxServerStatus. We will be able to see that we have 4 (four) operational replication hostnames: two Continuous Replication HostNames (S08-E2K7-CCR1BKP and S08-E2K7-CCR2BKP) and two server names. At the moment only the Host Names S08-E2K7-CCR1BKP and S08-E2K7-CCR2BKP are being used to replicate the CMS data. This means that the replication is occurring through a redundant or private network.
Now, let us validate the replication using the Performance tool. We will open the tool in the second node and we will add the performance counter called Bytes Total/Sec. From the object Network Interface we will also add the two instances Network card 1 and 2. After sending a message of 4MB to a user located in the CMS server, we will be able to see that replication is using the backup network instead of the Public Network, as shown in the example figure below from a test environment.
Mark Myers
Senior Consultant
Project Leadership Associates
3/23/2009
When Exchange 2007 Service Pack 1 runs under Windows Server 2008, clients who connect to Exchange 2007 via Outlook Anywhere may be repeatedly prompted for their credentials. The problem occurs when NTLM authentication is enable as a supported method of authentication for Outlook Anywhere as well as is the selected authentication method in the Exchange Proxy Settings dialog box for the Outlook profile on the client computer.
The difference between Windows Server 2003 and Windows Server 2008 is that by default Kernel Mode Authentication is enabled in IIS 7.0 (Windows Server 2008) but not on IIS 6.0 (Windows Server 2003), to resolve this problem, we need to disable Kernel Mode Authentication on all Exchange 2007 Client Access Servers (CAS) that are running on Windows Server 2008.
To disable Kernel Mode Authentication on the Client Access Servers running on Windows Server 2008 perform the following steps:
- Open a command prompt window (Start – Run – cmd.exe )
- Change Directory to %systemroot%\system32\inetsrv\ (cd %systemroot%\system32\inetsrv\)
- Run the following command: AppCmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false
For more information about Exchange 2007 Outlook Anywhere visit http://technet.microsoft.com/en-us/library/bb123889.aspx
Jose Girbes
Senior Consultant
Project Leadership Associates
3/4/2009
In the current economic climate, it's not surprising that all IT departments are looking to save on costs. If you're presently looking at migrating a GroupWise or older Exchange system to Exchange 2007, you may be concerned with the time and resource cost of performing the migration and getting everything right. Over the last several months, I've had customers express this very concern. They want to convert/migrate to Exchange 2007, however, they just want it to be low cost, simple, and not a lot of user impact. Which is typically easier said than done when you look at the task of moving gigabytes of email from older legacy systems to Exchange 2007. Not only is the mailbox size a factor, but there are also GroupWise archives and/or Outlook .PST files to consider.
If you're migrating from GroupWise to Exchange 2007, chances are, you are already looking at using Quest Software's GroupWise Migrator for Exchange. It is pretty much the defacto GroupWise migration tool. If you're looking into an Exchange to Exchange migration (either intra-forest or inter-forest) you may have been looking at Quest Migration Manager for Exchange.
If you are using one of these tools, by adding Quest Archive Manager into the mix, you can greatly reduce the time and cost of your migration effort. And, even if you're not using these tools, you can still use Quest Archive Manager to reduce your migration costs.
The methodology use for this approach is called "Archive before you Migrate" and is becoming one of the more popular migration scenarios. To perform a migration using this method, you configure Archive Manager to use the existing legacy email system (GroupWise or Exchange 2003/2000) and being archiving all of your mail and import all applicable GroupWise archives and/or Outlook PST files. Essentially, you want to pick a date and time to archive up to. A good target example is 90-120 days and older email is placed into the archive.
Once all the older email is in the archive, you perform a standard migration, but filtered by date. The big difference here is that you only migrate 90-120 days worth of email into Exchange 2007, rather than all the email that has been stored on your legacy system. The older email is retained in Quest Archive Manager, and as mailboxes are migrated a process is done to reconnect the Archive Manager mailbox to the new Exchange 2007 mailbox. Thus, instantly bringing all the legacy email content from the old system to the new system nearly instantaneously.
The cost savings from doing this method can be quite significant, as Quest Archive Manager allows for the following:
- Single instance storage across the Enterprise. Messages in archive manager are only stored once per Archive Manager instance.
- Ability to use low cost storage solutions for attachment data. Archive Manager function extremely well on SATA drives and NAS solutions, as opposed to expensive Exchange 2007 SAN storage solutions
- No client is required to access Archive Manager, as it is a web based application. Therefore, a costly rollout to clients is not required.
This is just a short list that does not cover all Quest Archive Manager features, but simply highlights the big cost saving features for doing an "Archive before You Migrate" solution. More information about Quest Archive Manager can be obtained from the Quest Software website at http://www.quest.com/archive-manager.
Eric Gentry
Senior Consultant
Project Leadership Associates
3/1/2009
Establish E-Mail Coexistence (Enabling Directory Synchronization)
In the first part of a three part series we provided instruction in how to add and verify your organizations domain to Microsoft Online Services. In the second part we explained the establishment of email flow. We will now explain Enabling Directory Synchronization. I have decided to save the migration of mailboxes for a continued and separate two part blog based on the level of detail that needs to be covered just on migrations to the "cloud". Watch for "Migrating Mailboxes to the Cloud Part 1 and 2"
Enable Directory Synchronization
We now need to enable directory synchronization before we install the Directory Synchronization Tool.
To enable directory synchronization
- Sign in to the Microsoft Online Services Administration Center, click Migration, and then click Directory Synchronization.
- Complete the first step on the Directory Synchronization page by reading the plan for directory synchronization.
- Under step 2, "Enable one-way synchronization from your local Active Directory to Microsoft Online Services" click Enable.
Our next step will be to Install and Configure the Directory Synchronization Tool
Directory Synchronization Tool
There are some minimum requirements for the installation of the Directory Synchronization Tool, these requirements are as follows.
- A Windows 2003 (x86) not (x64)
- A member server of the local Active Directory forest that is to be synchronized
- The server cannot be a domain controller
- Required Directory Synchronization Permissions
The Directory Synchronization Tool will require the following permissions.
- Local Administrative permissions on the Windows 2003 server.
- The Administrative account with administrative permissions on MSONLINE.
- User name and password of an account with Enterprise Admin permissions on your local Active Directory service.
- Exchange Administrator permissions to implement TLS in your Exchange Server environment.
We will now install the Directory Synchronization Tool.
To install the Microsoft Online Services Directory Synchronization Tool
Sign in on the Microsoft Online Services Administration Center on the Windows 2003 computer which will host Directory Synchronization, click Migration, and then click Directory Synchronization.
- Download the Directory synchronization tool to the Windows 2003 computer.
- At the end of the installation you will be prompted as to whether you would like to start the configuration wizard.
- On the Finish page, select Start Configuration Wizard now, and then click Finish.
- Provide the user name and password for a user account with Administrator permissions in Microsoft Online Services.
- On the Active Directory Credentials page provide the user name and password for an account with Enterprise Admin permissions on your local Active Directory directory service.
- When Configuration is complete you will see the following dialogue
- On the Finish page, select Synchronize directories now, and then click Finish.
- Validate that Directory Synchronization has taken place by going to the Users Tab on MSONLINE, selecting User List and viewing Disabled user accounts. In the following screen I can see some of my disabled users recently synched based on the creation of a "New View" using the Active Directory Department field of "Executive Branch". "Executive Branch" had been populated from the Department field in a previous Active Directory Synchronization. In this way, while I cannot prevent all users from coming into MSONLINE. I can at least filter them into different views using this method.
How often does Directory synchronization Take Place?
Directory Synchronization will now take place once every three hours. If you change the password on MSONLINE or within your Active Directory you will need to rerun t the configuration tool again.
Forcing Directory Synchronization
If you would like to force directory synchronization outside of the three hour interval you will need to run the tool again and on the Finished Dialogue Box as before select the "Synchronize directories now.
You can run the tool again by Clicking Start, click All Programs, click Microsoft Directory Sync, and then click Directory Sync Configuration.
What will be synchronized?
All accounts will be synchronized to MSONLINE but will be disabled by default. These will not count against your used MSONLINE licenses until you enable them which will be discussed as part of Mailbox Migration.
This synchronization process is one way, with your internal Active Directory serving as the Authoritative source and the MSONLINE directory serving as a read only copy of the directory.
Watch for my next two blogs "Migrating Exchange Mailboxes to the Cloud Part 1 and 2".
Forrest McDuffie
Senior Consultant
Project Leadership Associates
This blog provides a great link to download a Word document with a questionnaire users could fill out and return to an administrator to aid in troubleshooting RPC communication failures. Grab this one!
Mark Myers
Senior Consultant
Recently, I was testing SCR and CCR replication and needed to quickly create specific large-sized text files to be used as an attachment to mail messages. While there has to be thousands of ways to do this, one of the easiest ways is to uses the FSUtil utility. Get to a command prompt and enter the following:
FSUtil file CreateNew c:\new10MBFile.txt 10000000
The FSUtil utility will create a text file, based on my example, of 10MB in size, in the location specified. Now, simply use this file as your attachment to quickly fill up those 1MB log files you need for your testing.
Note – you must be logged on as a member of the Administrators group – or be an administrator - to use FSUtil.
Mark Myers
Senior Consultant
I wanted to document the procedures to testing CCR failover scenarios. I wanted this procedure list to be short and easy – quick to execute to determine if the two CCR nodes were operating properly. The procedure with the Exchange Management Shell cmdlets is presented here. The procedures listed will work when using Windows Server 2003 or Windows Server 2008.
Assumptions
- The two CCR nodes are called CCRNode1 and CCRNode2.
- The CMS is called CMS
CCR Testing
Active node has E00.log; passive node only has E00.chk file – no E00.log on passive.
Public NIC Failure Test
This test simulates the failure of the public NIC on the active node.
- Connect to active node – CCRNODE1.
- Note presence of E00.log file on CCRNODE1. Passive node does not have E00.log file.
- Disable public NIC.
- Failover Clustering Manager shows resources going offline and moving to CCRNODE2 node.
- Execute Get-StorageGroupCopyStatus on machine with disabled NIC to see errors in not finding Active Directory DC. No client traffic now occurs over this public network – no users can access this node.
- Outlook clients can connect to mailbox on CMS now on CCRNODE2.
- Test inbound Internet mail to test mailbox on CMS.
- Enable public NIC on CCRNODE1.
- Issue Get-ClusteredMailboxServerStatus on CCRNODE1. Note it indicates CCRNODE2 is active. Issue same cmdlet from CCRNODE2 to verify it also shows it's the active node.
- Connect to CCRNODE2 to verify the presence of E00.log.
Note – state of databases may show as Initializing. What initializing is telling the administrator is that:
- The replication service has not received a notification to copy a log.
- The replication service has not yet copied a log.
- The replication service has not yet inspected a log.
- The replication service has not placed a log out for replay and determined divergence information.
To change replication to a healthy state I usually do one of two steps:
- Dismount and re-mount all databases -> this should cause log roll to occur and the replication service to replicate a log.
- Create test mailboxes in each store and send mail to them. Mail flow will create log files. If the mail flow is not significant enough to roll the logs, automatic log roll will occur at a later time even though the log file is not full.
- Perform a Move-ClusteredMailboxServer -id "CMS" -TargetMachine CCRNODE1 -MoveComment "Move CMS back to CCRNODE1 after public NIC testfailure"
- Verify the presence of E00.log on CCRNODE1, and that the E00.log file is not present on CCRNODE2 (now passive node).
-
Perform these three standard tests:
- Test-ReplicationHealth
- Get-ClusteredMailboxServer
- Get-StorageGroupCopyStatus –ID CMS
to validate all clustering and replication is healthy.
End of Public NIC Test
Private NIC Failure Test
This test simulates the failure of the private NIC on the active node.
- Verify CCRNODE1 node is active.
- Disable private NIC on active node.
- Issue the following standard test cmdlets and note the results:
- Get-ClusteredMailboxServer
- Get-StorageGroupCopyStatus –ID CMS
- Test-ReplicationHealth
Note the first two cmdlets show normal online and healthy status. The replication health result shows an error for the ClusterNetwork and an error on the private internal network, as expected.
- Re-enable private NIC on active node.
-
Perform these three standard tests:
- Test-ReplicationHealth
- Get-ClusteredMailboxServer
- Get-StorageGroupCopyStatus –ID CMS
to validate all clustering and replication is healthy.
- If the storage group does not come online, stop and start-ClusteredMailboxServer.
- Check Failover Cluster Manager for resources that may need to manually come online.
- Perform the standard three testing cmdlets once again to verify correct function.
End of Private NIC Test
Database Failure Test
This test simulates the failure of one of the mailbox databases on the active node.
- Verify CCRNODE1 is active.
- Dismount active node Store1.edb database simulating a database failure.
- CCR passive node CCRNODE2 will not provide service for this failed database – this is a manual recovery process involving the administrator back to the original active node. To simulate a real database failure, delete (or move) the SG1 logs and database files simulating a loss of logs and database files.
- A reseed from the passive copy to the active node is required. Suspend the copy process by executing the Suspend-StorageGroupCopy –id "EXCMS\sg1" cmdlet from the active node.
- Mount the database for SG1. Note the message regarding the creation of a new empty database.
- Execute the Update-StorageGroupCopy –id "CMS\sg1" –DeleteExistingFiles from the passive node. Note the warning message and choose to initiate and for possible reseeding of the checkpoint file. Note 2nd warning message and choose to initiate and for possible reseeding of the database.
-
Perform these three standard tests:
- Test-ReplicationHealth
- Get-ClusteredMailboxServer
- Get-StorageGroupCopyStatus –ID CMS
to validate all clustering and replication is healthy.
End of Database Failure Test
Failed Information Store Service Test
This test simulates the failure of the Information Store service on the active node.
- Configure the information store service on CCRNODE1 (active node) for a startup type of Disabled, and then stop the service. If the service was simply stopped manually, it would be restarted automatically and no changes to service or nodes would occur and service would resume normally. But, in this case, its startup type is set to Disabled to prevent the auto-restart.
- Failover to CCRNODE2 to fully recover from failed service using Move-ClusteredMailboxServer –id CMS –TargetMachine CCRNODE2 –MoveComment "Comment here"
- Correct failed service on CCRNODE1. Restart service.
-
Perform these three standard tests:
- Test-ReplicationHealth
- Get-ClusteredMailboxServer
- Get-StorageGroupCopyStatus –ID CMS
to validate all clustering and replication is healthy.
- Failback to CCRNODE1 if desired with Move-ClusteredMailboxServer –id CMS –TargetMachine CCRNODE1 –MoveComment "Comment here".
-
Perform these three standard tests:
- Test-ReplicationHealth
- Get-ClusteredMailboxServer
- Get-StorageGroupCopyStatus –ID CMS
to validate all clustering and replication is healthy.
End of Failed Information Store Service Failure Test
Active Node Failure Test
This test simulates the failure of the active node.
- Take CCRNODE1 active node offline completely.
- Note passive node CCRNODE2 comes online for the CMS for most or all resources. If CMS does not come online, try performing a Restore-StorageGroupCopy for that storage group. (Public folder will not come online – see bullet #4 below.
- If the previous cmdlet fails, execute Stop-ClusteredMailboxServer – then – Start-ClusteredMailboxServer.
- Verify in Failover Cluster Manager resource are online – manually attempt to bring any down online. For public folder storage group, it will never mount until original node is brought back online. For more information on public folders and CCR, see http://technet.microsoft.com/en-us/library/bb123996.aspx.
- To determine if databases have come online and have been mounted, execute Get-MailboxDatabase -status | ft name,storagegroup,mounted. This EMS cmdlet will return the database status much faster than using EMC.
-
When the failed node comes online, check the following and make necessary corrections:
- Bring online the public folder resource/storage group.
- For any other database resources stuck in initialization state, attempt to Stop and Start-ClusteredMailboxServer to bring online.
End of Active Node Failure Test
Mark Myers
Senior Consultant
2/16/2009
Securing your email connectivity
This next section I am writing as I am on a plane flying from Chicago to Seattle for the Exchange 14 Airlift. I will be writing more about Exchange 14 in the coming months once Exchange 14 has become public, but for now let's continue on course in our next of a three part series surrounding MSONLINE also known as BPOS or Business Productivity Online Suite. Our next requirement in the configuration of Exchange online is to secure our email traffic between our internal organization and MSONLINE. This is highly recommended as your internal organizations email will now be traveling over the internet during co-existence. We will encrypt our email between both the internal environment and our external environment by the use of TLS (Transport Layer Security).
Certificate Requirements for TLS
To secure the email between the two environments we will need to utilize a trusted third party certificate.
Your Exchange environment will have a set of its servers which are responsible for communication of internet mail to and from the Internet. These servers are typically known as Bridgeheads in Exchange 2000 and 2003, Hub Transports, or Edge Servers in Exchange 2007.
Each of the servers responsible for internet email flow will require the third party certificate and a connector configured for TLS. This will not be needed on your Backend or Mailbox servers unless these servers are also acting as your Bridgeheads in the case of Exchange 2000 or 2003 or share the role of Hub Transport in the case of Exchange 2007.
If you have separate bridgehead servers for sending and receiving e-mail via the Internet, you will need to acquire and install a certificate on each SMTP server sending and receiving email to and from the internet that is running Exchange. You will need to set up a connector and enable TLS only on the server or servers that are used for sending e-mail to and from the Internet.
Of course if your email is relayed to and from the Internet by a third party outside of Exchange this will need to be configured for secured email traffic via TLS per the vendors requirements. Follow the steps per http://go.microsoft.com/fwlink/?LinkID=117208&clcid=0x409 to acquire certificate which will include the following.
- Perform a certificate request via IIS for Exchange 200x or via PowerShell for Exchange 2007.
- Obtain the certificate, for Exchange 2007 the recommended certificate type will be a Unified communications certificate also known as a SAN (Subject Alternative Name) certificate.
- You will need to ensure that the certificate is from a recognized third party. Self signed certificates now found on Exchange 2007 cannot be used for this purpose when configuring TLS with Exchange online.
- Use ESM to install the certificate for Exchange 200x or PowerShell in the case of Exchange 2007.
- Now create an SMTP connector for Exchange 200x or a send connector for Exchange 2007.
To create an SMTP connector for Exchange 200x
- In Exchange System Manager, right-click Connectors, and then select New SMTP Connector.
- Type a name for the connector, which in my example will be known at MSONLINE.
- On the General tab, select Forward all e-mail through this connector to the following smart host, and then type mail.global.frontbridge.com.
- Under Local Bridgeheads, click Add, and then select your Exchange Bridgehead Servers.
- On the Address Space tab, click Add, followed by your Microsoft Online Services e-mail routing domain in my case msmcduffie1.microsoftonline.com which will have been assigned to you when signing up for BPOS.
To create a SEND connector for Exchange 2007
- See how to Create a New Send Connector at http://technet.microsoft.com/en-us/library/aa998814.aspx
Configure TLS for the Exchange 200x server sending and receiving email
- For Exchange 200x in ESM, expand Connectors and find the MSONLINE connector previously created.
- Right-click the connector, and then click Properties.
- On the Advanced tab, click Outbound Security, and then select TLS Encryption.
Precursors to sending email to and from Exchange Online
Now we are ready to test email flow between the internal organization and Exchange Online. This will require the creation of an Exchange Online mailbox and of course one internal mailbox. Additionally the following is assumed.
- The internal organization is registered on the internet and has a valid MX (Mail Exchange) record.
- You have established that email flow works to and from another internet bound registered email domain.
- You have a registered domain name with Microsoft Online usually in the form of msyourcomanyname1.microsoftonline.com.
- The Exchange online test user now exists with an email address in the form of useremailalias@yourorganization1.msonline .com
- You have a user in your internal organization from which you can send email to and from the internet.
Now it is time to validate email verify your e-mail traffic flow
- Log on to your internal test mailbox and send an email to your Exchange Online test user at useremailalias@yourorganization1.msonline.com which in my case is test1@msmcduffie1.microsoftonline.com.
- Log on to Microsoft Online Services and start OWA as useremailalias@yourorganization1.microsoftonline.com
- Validate the receipt of the email message from your internal user.
- Now send an e-mail message to your internal user which is in my case is fmcduffie@oswegohomesil.net .
- Verify receipt of the message from your MSONLINE account within the internal user.
- Reply to this message and validate receipt by the MSONLINE user.
- Reply to this message and validate receipt by the internal user.
In part 3 of this 3 part series we will discuss Enabling Directory Synchronization and migrating your first Mailbox to Exchange Online.
Forrest McDuffie
Senior Consultant
Project Leadership Associates
|
|
|
|
|
|
|
|
 |
|
|
|
|