Error (10698)
Virtual Machine TEST could not be live migrated to virtual machine host HYPERV01 using this cluster configuration.
(unspecified error (0×80004005))

I will not bother you with the troubleshooting steps taken, but after enabling IPv6 on the NIC’s of the HYPER-V hosts used for managing the host, live migration worked fine.
So yet another reason why you should not disable IPv6 !!

=============================================================================
“attributeId” attribute value for objects defined in Windows 2000 schema and extended schema do not match.

A previous schema extension has defined the attribute value as “1.2.840.114050.1.1.1.1.90″ for object “CN=preferredLanguage,CN=Schema,CN=Configuration,DC=Contoso,DC=com” differently than the schema extension needed for Windows 2003 server .
[Status/Consequence]
Adprep cannot extend your existing schema
[User Action]
Contact the vendor of the application that previously extended the schema to resolve the inconsistency. Then run adprep again.

 =============================================================================
“isSingleValued” attribute value for objects defined in Windows 2000 schema and extended schema do not match.

A previous schema extension has defined the attribute value as “FALSE” for object “CN=preferredLanguage,CN=Schema,CN=Configuration,DC=contoso,DC=com” differently than the schema extension needed for Windows 2003 server .
[Status/Consequence]
Adprep cannot extend your existing schema
[User Action]
Contact the vendor of the application that previously extended the schema to resolve the inconsistency. Then run adprep again.

==============================================================================

I opened up a PSS Support call because I am always carefull with schema issues. Better be safe than sorry. Microsoft suggested to run the renameattribute.exe included in the hotfix explained in KB293783.  The KB is referring to ” Unix services for windows”  which caused the problem. The renameattribute did not solve the problem.

After a talk with the sysadmin that was working with the company the longest, he remembered that years ago there was an issue when the COGNOS application was implemented. He remembered that they did an schema extension on the AD. Because there were a lot of problems with the AD integration, the AD integration was cancelled.

The Attribute PreferredLanguage was implemeted by COGNOS with the wrong OID. After checking the AD that the attribute was not used by any user object, I renamed the ldapdisplayname, admindisplayname and the RDN of the attribute preferredlanguage to COGNOSpreferredlanguage. After the change the forestprep worked without any errors!

I have been using the ADExplorer tool from sysinternals and I liked it very much. It is way better than working with ldp.exe from MS.

Please be very carefull when making changes to the Active Directory Schema ! Making changes in the schema is always at your own risk !!

Use ADSI Edit (included in Server 2008) and connect to the Default Naming Context.
Locate the Service Account, open the security tab.
Select SELF in the group or user names windows and check the Allow box for  ”Write public information” .

SELF permissions

After making the change restart the SQL Server service. The Service Account will register the SPN automatically.

To check if the SPN’s are registered correctly open a command prompt and do:
setspn -L Serviceaccount (e.g. SA_SQL2008_01)

The output should look like:
Registered ServicePrincipal Names for CN=SA_SQL2008_01, OU=Service Accounts, DC=Contoso, DC=com

MSSQLSvc/FQDN:1433

Works like a charm.

To be able to use the Single Sign On feature which is included in the RD Web Access you need to sign your RemoteApp’s with a certificate. How you can set this up is explained in an article on the Microsoft RDS Team Blog.

After implemting the RemoteApp signing you’re not quite finished. The following happens: Every time a user clicks on one of the RemoteApp a security warning comes up which states: A Website wants to run a RemoteApp program. Make sure that you trust the publisher before you connect to run the program.

 Of course this is very annoying and we want this security warning to disappear. There are two ways to do this.

1. Changing logon settings.

When you log on to the RD Web Access web page you can choose whether you are on a public or on a private computer.

 If you change the radio button to Private computer before you logon to the RD Web Access web page the security warning still comes up, but you will see a checkbox you can enable to never warn you again for this and the pop-up will dissapear the next time you will click the RemoteApp.

 2. Create a GPO with .rdp signing settings

You can also create a GPO with the follwing settings:

{Computer | User}\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Connection Client

“Specify SHA1 thumprint of certificates representing trusted .rdp publishers”  and enter the SHA1 thumprint of the certificate you use for signing your RemoteApp’s.

You can find the SHA1 thunmprint on the details tab when you open the certificate.

 When you use this second option your users do not need to change the logon radio button whether they are on a private or public computer.

I have had some discussion with the guys @ Microsoft from the RDS Team. They came up with the what I call workaround. Because it seems that there are no real solutions available at the moment because the behaviour is “By Design”. Microsoft promised to get back to me when they find a better option to solve this issue because the workaround does not work for users who are working on non-domain joined workstations where we cannot apply GPO’s. Users on non-domain joined computers will always get the security warning.

Of course I will publish my Agenda of this Blog when it is ready. I am planning on placing a lot of the information I receive on Teched onto this website. So be prepared for a load of information after 13 November when I will be back in the Netherlands !