Free E-book about Windows Server 2012

I haven't had a chance to read it yet, but Microsoft has made an e-book about Windows Server 2012 available free for download. You can get it here:

• Free E-Book Offer: Introducing Windows Server 2012

Sending Email from a PowerShell Script

As I move more batch jobs and scheduled tasks over to PowerShell, I've found that I often want to send some sort of status message when a script completes. The .NET Framework, which PowerShell uses, includes the Net.Mail.SMTPClient object that you can use to send email messages.

First you need to create a new instance of the object in a variable:

$mail= New-Object Net.Mail.SmtpClient("IPorDNSofSmtpServer")

Then, you can send the message:

$mail.Send("FromAddress","Recipient1,Recipent2","Subject","Body")

In most cases, you would use variables to define the addresses, subject, and body of the message.


Some potentially useful documentation:

• http://msdn.microsoft.com/en-us/library/system.net.mail.smtpclient.aspx
• http://msdn.microsoft.com/en-us/library/system.net.mail.smtpclient.send.aspx

KB 2720211 Kills WSUS

Updates were performed on a client's WSUS 3.0 SP2 server this week and KB 2720211 killed WSUS. Here are the symptoms we saw:

• WSUSDB in single user mode (done as part of the failed update process, but not undone when the update failed)
• Named pipes disabled (also I think done as part of the failed update process).
• MMC for WSUS fails with "MMC has detected an error in a snap-in"

After doing some research, it seems that this update causes a problem for some servers and not others. This particular server Windows Server 2008 R2 64-bit. I'm not sure if that is part of the issue.

The resolve is:

• Use SQL Server Configuration Manager to enable named pipes
• Use SQL Server Management Studio to change the database to MULTI_USER
• Stop the Windows Update service and World Wide Web Publishing service before connecting to allow you to use the single connection that is available.
• Copy some files manually from the update into their correct location. I'm not sure why but it appears on some systems this is not being done.
• Download and run WSUS-KB270211-x64.exe /extract to extract the files.
• Use a program capable of extracting CAB files (7 zip) to open PCW_CAB_SUS and copy the files DbCert, DbCertDll, and DbCertSql
• Rename those files to WSUSSignDb.cer, WSUSSignDb.dll, and WSUSSignDb.sql.
• Copy the cer and dll file to: C:\Windows\Sysmsi\ssee\mssql.22005\mssql\schemasig
• Copy the sql file to C:\Program Files\Update Services\Database
• Rerun the update

Some others have also reported that there is a DCOM error that needs to be resolved.

For a great detailed description of how to resolve this look for the post by chucker2 in the microsoft forum link:

• http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/e918a191-ef6d-4c4b-b83a-7a4ae20a5217

Some others have reported that a registry key needed to be modified in order for the update to install properly. Or perhaps, this is just an easier fix than the above. See this link:

•  http://msmvps.com/blogs/bradley/archive/2012/06/12/kb2720211-issues.aspx

Operations Manager Web Part Error

I created a lab exercise for course 10751A: Configuring and Deploying a Private Cloud with System Center 2012 that includes an Exercise on installing the new Operations Manager Web Part. This web part displays Operations Manager dashboards in SharePoint sites. By default, the dashboard is accessed based on the credentials you used to log on to SharePoint, but you can override this and use a single set of credentials for all users. This is useful when providing status information to people that do not have Operations Manager permissions.

As part of configuring the web part, you need to copy two encryption keys from the Operations Manager Web console into SharePoint. In earlier testing, with beta and release candidate software, this worked flawlessly. In our testing with RTM software we ran into a weird intermittent error where the dashboard could not be accessed by using the shared credentials.

In the web part the following message is displayed:

An unexpected error has occurred.

If you click the link to show error details, you see the following:

Microsoft.EnterpriseManagement.Presentation.Security.ConnectionSessionException: Unable to create connection session.

Imagine my concern when using the detailed error message resulted in zero results on Google. So, we tried a whole bunch of things, but what fixed it was uninstalling the Operations Manager Web console and reinstalling it. This regenerates the encryption keys in the Operations Manager Web console that are used for connectivity from SharePoint. After SharePoint was updated with the new encryption keys it worked without any issues.

I did verify that the shared credentials were being passed properly to the Operations Manager Web console. You can see this in the log for the Operations Manager Web console web site. No errors were displayed in that log. So, it must have been something at the .NET level which is a bit outside my area of expertise.

Ultimately, I don't know whether the encryption keys were the problem or the Operations Manager Web console was the problem. Uninstalling and reinstalling the Operations Manager Web console could have fixed either one.

Detailed steps for configuring the Operations Manager Web Part and shared credentials are here:

• http://technet.microsoft.com/en-us/library/hh212924.aspx

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.