I was assisting a colleague which was installing the Ax 2010 Enterprise Portal on a SharePoint Farm. The farm consisted of 2 servers hosting the SharePoint web applications (the actual sites), and 2 servers hosting the central admin and application services roles. We wanted to start with installing the Enterprise Portal bits on both web front servers without actually choosing the “create site” option in the installer. This would just prep the server and then we’d finalize it by running the “create site” option on the central admin server.

Here’s the screenshot where we selected the Enterprise Portal (and some other prereqs for the Portal):

Some steps further we were supposed to get a dropdown with an overview of all sites hosted by SharePoint. Although SharePoint was installed, and we had multiple sites created, we were greeted with an error stating “Microsoft SharePoint 2010 is not installed or running. Please run the prerequisite utility for more information. Operation is not valid due to the current state of the object.”

Going back and clicking next again doesn’t really solve the problem. Going to the installer log file (which is located in \Program Files\Microsoft Dynamics AX\60\Setup Logs\[Date]) showed us that the installer seemed to query the local IIS configuration just fine. As far as I could tell no actually error was given, but it started processing shortly after trying to get information regarding the first actual SharePoint site.

After staring a bit at the log my eye fell on the “GetFirstHostHeaderOfWebSite” method. It seemed to have ran fine for the default website, but it wasn’t executed for the first actual SharePoint site. And it rang a bell as we have customized this a bit. We had in fact 3 host headers for each SharePoint site. One for the virtual name, one for the virtual name but dedicated to the node and one which was just blank with the IP. I know the last one more or less make the others unnecessary, but we added that one later on when we figured our hardware load balancer status probing wasn’t playing nice with the host headers.

Long story short, after modifying ALL sites found in the IIS configuration so that thed have one or no host headers, the setup was able to enumerate the potential sites to configure the AX Enterprise Portal for just fine. Bit weird and seems like a bug in the installer to me…

Recently some colleagues of me logged a case because a GPO which worked fine before didn’t seem to work anymore. In the GPO the security of c: was redefined. In the end the root cause of that problem was McAfee. Whilst troubleshooting with Microsoft, in one of the generated log files we noticed SYSVOL mismatch errors.

When troubleshooting GPO’s often an utility called GPOtool.exe is used. This tool is available in the Windows 2003 resource kit tools. Since that tool I’ve never seen a newer version been released. I always assumed it just worked with Windows 2008 or 2008 R2 Domain Controllers. So when we got the following errors, we assumed we had a problem with some of our GPO’s:

In words: Error: sysvol mismatch. At first sight the version in the output seem identical. Also when verifying using ADSIedit, the GPO Management Console & in the SYSVOL share, all GPO related versions seemed to be correct. One thing we noticed though, only GPO’s which were exported and imported in a newer GPO seemed to be mentioned. Although I see no reason for that to cause versioning issues. After some googling I came across this: http://kb.elmahdy.net/2011/02/gpotool-for-windows-server-2008-r2.html

So it seems Microsoft (internally) has a more recent build of GPOtool.exe which plays nicer with Windows 2008 R2 domain controllers. I am by no means responsible for the tool provided on that blog, but I tested it in my environment and it worked fine. The exe seems to be signed by Microsoft, so I would assume it’s safe. To conclude the correct output:

And some GPOtool.exe version information (gpotool1 is the old one):

P.S. It is to my understanding that the Windows Server 2012 will have a GPMC which has enhanced capabilities regarding the GPO health. Way to go!