Setting Up a New Exchange Server

On a pretty regular basis I see requests in support forums about setting up new Exchange servers and verifying functionality. So, first I’d like to discuss the overall configuration and then how you can test it. I’m going to assume, you’ve already installed Exchange.

Authoritative Domains

The domain name that you use for email such as, conexion.ca, must be configured as an authoritative domain in Exchange Server 2010. Doing this tells Exchange that it is responsible for that email domain and should accept messages for it. The steps on how to configure an authoritative domain are here: http://technet.microsoft.com/en-us/library/aa996314.aspx.

E-mail Address Policy

To give your users email addresses, you need an email address policy that contains your domain name and the format of the email address that you want to use. The default may or may not be what you want. Any new email address policies you create have a higher priority than the default. More information about configuring email address policies is here: http://technet.microsoft.com/en-us/library/bb232171.aspx.

Mail Flow from the Internet

Mail messages from the internet can be delivered directly to your email server or go through an SMTP relay. The SMTP relay is in a DMZ (perimeter network) and performs antivirus and antispam scanning before passing messages to your internal system. If you have an SMTP relay then you need to configure your external firewall to forward port 25 to the SMTP relay. Then configure the SMTP relay to forward messages to the Exchange server on the internal network.

Most of the Microsoft documentation for Exchange assumes that you are using an Edge Transport server for SMTP relay. However, this is not required. In fact, most organizations that I work with do not have an Edge Transport server. They have a third party product that performs the role of an SMTP relay.

Many smaller organizations do not have a DMZ and forward port directly from the external firewall to the Exchange server. In most cases, this is fine. It all depends on how security paranoid you want to be. The use of an SMTP relay is more useful for offloading the work of anti-spam and anti-virus from the main Exchange server than it is at any sort of security.

Receive Connectors

By default, Exchange Server 2010 has a receive connector configured to listen on port 25. However, it does not accept unauthenticated connections. To allow this connector named “Default servername“ to accept messages from the Internet, you need to modify the properties and all Anonymous authentication.

For more information about receive connectors see: http://technet.microsoft.com/en-us/library/aa996395.aspx

Allowing anonymous authentication does not make your Exchange server an open relay. This connector will only accept messages for internal recipients.

Send Connectors

Exchange Server 2010 used send connectors to figure out how to deliver messages outside of the Exchange organization. There are no send connectors created by default. To allow message delivery to the Internet you need to create a send connector with the scope  of *. \

You also need to configure how the send connector delivers messages. By default it will use DNS settings and attempt to deliver directly to the Internet. This is appropriate if you do not have an SMTP relay. If you have an SMTP relay, you should configure it to send messages to the SMTP relay. Some people also choose to relay outgoing messages through their ISP. Be aware that if you are relaying out going messages through an SMTP relay or your ISP, then you can’t check delivery status in the queues of your Exchange server.

For more information about send connectors see: http://technet.microsoft.com/en-us/library/aa998662.aspx

DNS Records

Finally, you need DNS records that allow other people to find your email servers. For an email domain you need two records:

•  Host (A) record such as mail.conexion.ca that resolves to the external IP address on your firewall.
•  Mail Exchanger (MX) record for the domain that point to the host record.

Internet mail servers lookup and MX record for your domain then based on that MX record they are directed to your server name and IP address.

Testing Incoming Mail

The fastest way to test incoming mail is by sending a test message from another system. However you can also:

• Use Telnet. If you use Telnet (or PuTTY a better choice) you can connect directly to port 25 and see if it’s working. For more information see:  http://support.microsoft.com/kb/153119.
• Use the Microsoft Remove Connectivity Analyzer. This web site provided by Microsoft can test mail delivery and report back if it finds any errors. See: https://www.testexchangeconnectivity.com/

Be aware that many ISPs block all inbound and outbound traffic on port 25 if you do not have a business account and a static IP address. They do this to stop malware on client computers from sending out spam.

Convert a String Variable to a Secure String

When you are working with cmdlets that want passwords, the cmdlets require the password to be a secure string rather than a regular string. A secure string is encrypted in memory. When you read data from a csv file, it is automatically imported as a regular. To read a password from a file and use it, you need to convert it to a secure string.

To convert an existing string to a secure string use the following:

$SecurePass = ConvertTo-SecureString $UnsecurePass -AsPlainText -Force

After converting to a secure string, you can use it as a password when create user accounts with New-ADUser or as part of credentials you are passing to a cmdlet.

For more information about working with passwords, secure strings, and credentials see the following TechNet article: http://social.technet.microsoft.com/wiki/contents/articles/4546.working-with-passwords-secure-strings-and-credentials-in-windows-powershell-en-us.aspx

Recovering a Failed RAID 5 Array on a PERC Card

One of our clients had the misfortune to have a RAID 5 array get corrupted last week. When you went into the configuration of the RAID card and looked at the virtual disk, 1 disk in the array was shown as missing, 1 online, and 1 offline. The disk that was missing was actually marked as foreign, which means that it is not recognized as part of the virtual disk.

To make it even more fun, the RAID 5 array was also the boot disk.

Step 1 for recovery, force the offline disk to online. With three disks in a RAID 5 array, two online should have all of the data and be OK. However, it was not to be. The drive was still not accessible.
I added a new disk and made a parallel install of Windows so I could see what was going on. The partition that should have had all the data was corrupted in some way with the partition type showing as RAW instead of NTFS.

I tried importing the foreign disk, but no such luck. Which makes sense as the RAID card thinks it is part of another virtual disk.

I did all of the data recovery stuff I could with software that scans the RAW data and attempts to recover files. All the while not modifying the corrupted volume. There was still one last hope.

My last hope was to recreate the virtual disk with the following steps:

1. Document the configuration of the virtual disk (stripe size, etc) because we need it later.
2. Delete the virtual disk. This does not destroy the data on the disk, it just removes the virtual disk from the PERC card configuration.
3. Clear the foreign status of the 3rd disk. Again, this does not delete data, it just deletes RAID configuration information.
4. Recreate the Virtual disk with the 3 drives, DO NOT INITIALIZE the disks, and use the settings recorded in Step 1. Initializing the disks would delete the data on the disks.
5. Restart the server and chkdsk performs major repairs to the RAID volume (whoo hoo, it sees NTFS now)

After the repair was complete, the system would boot, but Active Directory was corrupted. Based on that I wasn't sure what else would be corrupted. So, I took a copy of all data that might have changed since their most recent backup (that I'd already verified as good). Then I reinitialized the RAID 5 array to wipe the data, reinstalled, and did a full restore from backup.

The data from the repaired disk seems to be suspect. So, I don't think we'll have anything useful from it. For example, the Exchange databases were not able to be mounted.

My frustration was when looking at the RAID configuration that the documentation was very vague about what my options were. Hopefully the description of recreating the RAID volume gives someone else a little more confidence if he/she is going through the same process.

Renaming a Scheduled Task

It has never occurred to me before, but you cannot rename a scheduled task in Windows Server 2008. You can modify everything but the name.

Not really a big issue, but we had a scheduled task where the name included the time the action was supposed to occur and I had just changed that time. It could be confusing when the two don't match.

However, there is a work around:

1. Export the incorrectly named task as XML.
2. Rename the XML file to the task name that you want.
3. Import the XML file to create the renamed task.
4. Delete or disable to incorrectly named task.

Repairing a Failed WSS_Content Database

Let me start by stating that I am not a big SQL guy. I can find my way around when I have to, but I'm not in the expert zone. However, one of our clients just had a big issue with SharePoint 2010. Their server crashed and the WSS_Content database that holds the SharePoint site data was in Read Only mode. It was giving errors indicating that database files were not accessible. The log file was missing.

There are a lot of postings on the Internet about repairing databases in Emergency mode. However, only one had the process that worked for me in this case. Most articles just say to run DBCC CHECKDB with the REPAIR_ALLOW_DATA_LOSS option. However, my database was in Read Only mode and wouldn't allow it.

I was also unable to access any database properties through SQL Management Studio. So, I needed to perform most operations by using Transact-SQL when I was attempting to make repairs.

Here is the process that worked for me:

1. Take the failed database offline and make a copy of it to use as a backup just in case.
2. Stop all SharePoint 2010 services so that they are not attempting to log on to the databases.
3. Create a new database named Recovery that uses the same file names in an alternate recovery location
4. Take the new database offline
5. Copy the old database file to the recovery location and replace the new empty database file.
6. Start the Recovery database
7. Put the Recovery database into Emergency mode: alter database recovery set emergency
8. Put the Recovery database into single user mode: alter database recovery set single_user
9. Repair the database with the option to reset/recreate the transaction log file: dbcc checkdb ('recovery',REPAIR_ALLOW_DATA_LOSS)
10. Verify that the Recovery database mounted properly and I can view the tables.
11. Drop the existing WSS_Content database: drop database wss_content
12. Use SQL Management Studio to rename Recovery to WSS_Content.
13. Start all SharePoint 2010 services.
14. Verify that SharePoint 2010 is functional.

After doing some more research after the fact, it might have been possible to just kick it out of Read Only mode and do a repair. To take a database out of Read Only mode would have been done with: alter database WSS_Content set READ_WRITE

Resetting a Computer Account without Rebooting

Computer accounts in a domain have a password just like user accounts. These accounts have a password that is changed automatically in the background every 30 days. When the password on the account and the password stored on the member server or client computer get out of sync, then the trust relationship is lost.

When the trust relationship is lost, the computer can no longer authenticate domain users. This can cause applications to fail and prevent users from logging on. You can verify that the trust relationship has failed based on an event in the System log.

Windows XP would often allow users to log on with cached credentials after the trust relationship was lost. Windows 7 typically displays a message about the trust relationship being lost and prevents domain users from logging on.

The following process rejoins the domain without losing any computer account information:

1. Reset the computer account in Active Directory Users and Computers
2. Configure the computer as a member of a workgroup.
3. Rejoin the domain.
4. Reboot to complete the process.

 However, you can also do it in PowerShell without requiring a reboot:

Test-ComputerSecureChannel -repair