This is one of the cases where you get the feeling that things got messed up, and you simply do not know why or how to even begin to fix them. Story goes like this:
In preparation for an upcoming Exchange Server 2010 course that I’m scheduled to teach next week, I sat at home with my Dell XPS laptop (running with 8 GB RAM and a 258 GB SSD), installed VMware Workstation, and prepared a few base images of Windows Server 2003 SP2 (to be installed with Exchange Server 2003 in preparation for the migration labs), and Windows Server 2008 R2 (to be installed with Exchange Server 2010).
To prepare the images I installed 2 virtual machines, one with each operating system. I then updated each VM, installed some of the stuff I use in order to customize and prepare the machines for my personal preferences, and got ready to clone them.
As you probably know by now, and if you don’t, it’s about time, Microsoft-based operating systems use SIDs (Security IDs) that are generated as part of the initial setup of Windows. If you have more than one computer with the same SID, this could cause problems, and cloning a computer (either physical or virtual) without re-generating this SID can cause SID duplication. You can read my “Creating and Cloning Virtual Machine Images” article for more information.
Anyway, knowing this issue I was careful to run SYSPREP on both VMs before shutting them down and cloning the virtual hard disk files. However, as you’ll soon find out, it seems that I have neglected one little aspect of using SYSPREP on Windows Server 2008 R2.
However, at this moment I was not aware of any issues. I was under the impression that SYSPREP did what it was supposed to do – remove the machine’s SID and other settings, preparing it for cloning.
So, I cloned the VMs, and created this configuration:
- WIN2008-SRV1 – to be a Windows Server 2008 R2 Domain Controller, DNS server, and an Exchange Server 2010 running the CAS and HUB Transport Roles.
- WIN2008-SRV2 – to be a Windows Server 2008 R2 member server, and an Exchange Server 2010 running the Mailbox Role.
- WIN2008-SRV3 – to be a Windows Server 2008 R2 member server, and an Exchange Server 2010 running the Mailbox Role for my DAG demo.
- WIN2003-SRV4 – to be a Windows Server 2003 R2 SP2 Domain Controller for a second separate domain in a separate forest, DNS server, and an Exchange Server 2003 SP2.
- WIN2008-SRV5 – to be a Windows Server 2008 R2 member server in the second separate domain in the separate forest, and that would eventually be promoted to become a Domain Controller to that domain, and that should eventually be installed with Exchange Server 2010 running the Mailbox, CAS and HUB Transport Roles for my migration demo.
All was set to go. I installed the right Exchange Server 2010 roles on WIN2008-SRV1 and WIN2008-SRV2, and started to customize the Accepted Domains, E-mail Policies, Send and Receive Connectors and so on.
I opened Outlook Web Access (OWA) or what they call now as “Outlook Web App”. All seemed to be working like a charm.
And then it hit me.
I created a simple e-mail message to myself.
The e-mail message got stuck in the Drafts folder.
I did it again, and now I had more messages stuck in the Drafts folder.
I rebooted the Mailbox role server. I rebooted the CAS/HUB/DC server.
I looked and searched for more information on the Internet. I remembered that in Exchange Server 2007, if you had less than 4GB free space in the partition that held the Exchange database and queue, this could happen. If that is true, one needs to make the disk larger, if possible, or move the Mailbox databases, Queue Database and Queue Log to another empty drive. But in my case, the virtual disks were considerably larger (80GB) and had plenty of free disk space.
I even found this:
An e-mail message is not sent as expected when you send the e-mail message from Outlook Web Access and the Microsoft Dynamics CRM 3.0 client for Outlook is open
Not related to my case.
I continued to search on, and finally I got it.
Error: Not able send mail from OWA 2010. When I send mail, the emails go to Drafts Folder.
However, I knew that this was not my case, because I know for 100% that I used SYSPREP before cloning MY systems.
And then, like a hammer in the head, I remembered that I forgot to select the “GENERALIZE” option in SYSPREP. Unlike previous versions, it seems that this version will NOT change the SID unless you pick that option.
I immediately used PsGetSID to see if I was correct or not.
When I ran it on WIN2008-SRV2 I got this SID:
And when I ran it on WIN2008-SRV1 (the DC), I got the same SID:
There goes my lab!
Luckily, I still had my base images cloned, so I could scrap everything and re-build, this time, properly running SYSPREP with the GENERALIZE option!