Showing posts with label Active Directory. Show all posts
Showing posts with label Active Directory. Show all posts

Tuesday, January 15, 2013

Hyper-V Replica Broker: Cluster network name resource failed to create its associated computer object in domain


Cluster network name resource failed to create its associated computer object in domain...
As the title says, there is some permission issues in Active Directory.
A customer of mine was deploying Hyper-V Replica in their datacenter today, and everything seemed OK during creation.
However, after checking the roles afterwards, the Hyper-V Replica Broker was having some errors.
A closer look at the critical events for this source showed that the cluster account was not able to create child objects in the correct container in Active Directory.

The text for the associated error code is: A constrained violation occurred.

When you enable the Hyper-V Replica Broker Role within a Failover Cluster, you must specify a name for the role as well as an IP address. This is because the Hyper-V Replica Broker is a HA role, where the secondary replica servers will target this object during replication. It is just like any other active/passive cluster role.

The Cluster Name Object (hyper-v_cluster_name$) is responsible for the creation of objects, and if this object does not have the required permissions to create child objects in the same container where it lives, you will get this error.

Talk with your domain administrator to sort this out.
Normally the domain administrator will delegate control through Active Directory so that your CNO can create child objects.

After we fixed this, everything was in order and the Hyper-V Replica Broker role was Running, healthy and smiling.

Wednesday, December 7, 2011

Cannot generate SSPI context

It`s quite common (here in Norway) that some local hero have installed the Windows Server when the organization/company is really small (1-5 employees).
The thing I want to address is that when they do this, they normally install the Active Directory Domain Services role – along with DNS server.

What about the DHCP role?

Nope. They already got some internet connection delivered by their ISP, so the clients are already connected to the internet.

Brilliant, right?

For all the other natural causes that I could use as arguments against this setup, I`d rather want to mention a common error message that appear when they run their LOB applications that uses Microsoft SQL server for their databases.

“Cannot generate SSPI context”

This error message occurs on clients attempting to connect to a SQL Server on the network.

And this message is purely related to DNS.

When you have an Active Directory domain and the clients are using the “wrong” DNS, which in these cases is the router/firewall (default gateway) or an external DNS, they cannot use name lookups to verify the server name.
In short, the DNS server from their ISP have very little knowledge of the server who is responsible for their databases on their local area network.
Conclusion: If you`re running an Active Directory domain, whether you have one employee or 15, please use your internal DNS server so that name lookups and other AD-related stuff may occur.

Wednesday, December 22, 2010

Hyper-V and separate Active Directory Domain

Most of the time, I get my inspiration from the forums, where some interesting people asks a interesting question. Today, there was a thread about Hyper-V on separate domain, and what our recommendation was.

You may think that there is a good practice to make your Hyper-V host part of an AD DS directory. Yes, it is. AD DS centralize all access rights to servers and support the delegation of administration services. Especially when it comes to Failover Cluster, the Hyper-V nodes require an Active Directory domain. (Important: You can off course run your Hyper-V hosts in a workgroup (not domain joined) and have VMs that belongs to the domain. But you can`t use Failover Clustering with this configuration).
But sometimes you want to live in an ideal world and separate the Hyper-V hosts with the rest of your domain and create a ‘Utility Directory’ which contains only the Hyper-V hosts. The security and identity context for the networked services in your production domain would remain the same as it was, but the security context for your Hyper-V hosts becomes an independent directory.

But when is this necessary?

It depends. It`s really a question about security, policy, and the size of your network. Remember that you would need additional servers as well to manage this domain. This configuration ensures that end users not lives or operates in the same security context as your Hyper-V hosts.

Any thoughts?
Subscribe to: Comments (Atom)

AltStyle によって変換されたページ (->オリジナル) /