An error occurred with error code ‘2147504141′

I have decided to try and install / test the new Exchange 2010. I have downloaded the Beta from the MS site , prepared a Vmware environment with Windows 2008 Enterprise version.
Installed Windows , patched everything , promoted the machine to a DC and I started Exchange 2010 installation.
After promoting to DC , I remembered the computer name was something like : “PC2hjCJS-blablaxxx22×2″ and would not be nice when I will have to test OWA and other stuff so I renamed the DC into something more easy to type and started Exchange installation.
All the preparation tasks were complete now and Exchange started installing the roles and checking the perquisites for the roles installation.
When it came to the HUB installation I got a strange Error.

Error:
The execution of: “$error.Clear(); install-ExsetdataAtom -AtomName SMTP -DomainController $RoleDomainController”, generated the following error: “An error occurred with error code ‘2147504141′ and message ‘The property cannot be found in the cache.’.”.

An error occurred with error code ‘2147504141′ and message ‘The property cannot be found in the cache.’.

After digging a while on the web I saw that the error is generated because the IPV6 was ENABLED but did not had an IP address assigned.
You can read a bit more about this on this Technet post :

http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/8f6ff508-2c09-4140-ba14-eca32bc5bf1d/

I have then tried to manually assign an IP address to the IPV6 – Did not help
I have tried to totally disable IPV6 – it did not help
Tried to follow the instructions on the K952842 http://support.microsoft.com/default.aspx/kb/952842 – did not help

So on Exchange 2007 the install did not work without IPV6 enabled and now on the Exchange 2010 will not work without disabling it ?

Well after a while of trying all kind of stuff I just gave up.

Installed a new Windows 2008 (this time I did a standard edition , just to have some variation) and disabled IPV6 BEFORE I started the Exchange installation.
Patched with all the patches.
Renamed the machine.
Installed IIS and .Net 3.0
Disabled IPV6 on the network adapter and in the registry.
Promoted the machine as DC on a new forest.
Reboot
Started installation and everything went ok.

So my theory is : You need to disable the IPV6 BEFORE you even start the Exchange 2010 setup and BEFORE the exchange perorms all the test and the pre installation tasks and/or Install IIS after you renamed the machine.

So my theory is correct , at least for my environment.

IPV6 needs to be disabled BEFORE you start exchange 2010 installation tasks or Exchange / IIS does not like the fact that I renamed the  machine after IIS was installed ?

Feel free to come with any arguments and let’s discuss this further if you feel different.

Topology discovery failed, error 0×80040a02

I needed a new test bench for testing the Exchange 2007 for someone and I did not wanted to use some of the enw hwrdware so I installed Windows 2008 on an old HP ML350 server , patched everything promoted the machine to a DC and started installing Exchange 2007.

Well , first thing it will start bitching over that you are running with a dynamic IP configuration so I went and double checked but I remembered correctly. The IP was set to static.
Went and started the setup again and again started bitching about dynamic IP.
Well , it was only one way to make it stop , as on the IPV4 was running static , I just DISABLED the IPV6 Protocol as I was not using it.

Started Exchange installation and after performing the pre installation test it installed the management tools and started the Hub Transport role.
After a few minutes the installation stopped with an error but nothing was actually specified.
Started digging trough events and I discovered this error :

Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=3608). Topology discovery failed, error 0×80040a02 (DSC_E_NO_SUITABLE_CDC). Look up the Lightweight Directory Access Protocol (LDAP) error code specified in the event description. To do this, use Microsoft Knowledge Base article 218185, “Microsoft LDAP Error Codes.” Use the information in that article to learn more about the cause and resolution to this error. Use the Ping or PathPing command-line tools to test network connectivity to local domain controllers. 

Checked all the configurations , checked DNS , checked the LDAP , everything was actually ok.
Tried to reboot the server and re-start the installation process but still the same error.

After hours of debugging and checking configuration , changing DNS and all kind of stuff I found an article that suggested enabling IPV6.

I did  so and the error is gone. After rebooting the machine I was able to install the rest of the server roles and everything was ok.

So question is : Why in the bloody hell will MS have IPV6 installed by default and why would Exchange start bitching about Dynamic IP allocation on IPV6 if I don’t use it ? Why would an Exchange installation STOP without the damn IPV6 ??
MS Works in misterious ways.

So if you guys are trying to install Ex2k7 on 2008 remember to have IPV6 enabled !!

OCS Edge Server errors

I decided to start blogging this deployment as it might help others.

A few months ago we decided to implement OCS 2007 and we had setup a test environment.
We installed OCS 2007 standard edition with a front end machine and an edge machine.
We tested the setup for a month or so and we decided to implement it in production.

Now , the initial setup was on a single domain and everything worked perfect. The production environment it is a bit more complicated with a forest and 6 subdomains.

Installation was performed and everything worked fine until we started testing when some strange errors started to show up :

Failed to process data received from the client

Timed out waiting for client to present validation cookie

Over the past 0 minutes Office Communications Server has disconnected client(s) 1 time(s) because of timing out waiting for cookie to be presented. The last such client which was disconnected is “xx.xx.xx.xx:22851″
Cause: This can occur if client does not present a validation cookie within 20 seconds of getting connected
Resolution:
Check to make sure that the connection came from a trustworthy client. This could indicate an attack being mounted by a rogue client.

After digging a bit we also found the solution.
Due to the fact that we used our own intern ROOT CA to issue the SSL certificate for the INTERNAL Edge interface the clients were trying to connect to the internal Root CA to verify the SSL.

There are 2 solutions to this problem.
1. Open the firewall on port 80 towards the root CA .. which I do not recommend or

2. Use a SSL issued by an external Root CA.

Also a thing never documented by Microsoft.

We were using 1 SSL certificate with 3 different alternative names for all the interfaces : Edge , AV , Web conferencing but looks like this setup is not supported and if you are using one SSL with different alternate names on all the interfaces it seems that the clients can connect to the OCS server without any authentication … also the EXTERNAL users without a domain account can connect . So I suggest using different SSL’s for the interfaces.