Mostly when I have issues logging on to a server, it's due to DNS problems. Sometimes the secure channel is messed up, but the last time it was actually quit simple: there was no SPN for the server in Active Directory.

The error: "The security database on the server does not have a computer account for this workstation trust relationship."

On a windows 2008 server the setspn command is built in. When I exectued "setspn -l servername" it returned no spn's for the server. Simply running "setspn -r servername" fixed the whole thing, immideately allowing me to log on again.

Windows detected your registry file is still in use by other applications or services. The file will be unloaded now. The applications or services that hold your registry file may not function properly afterwards.

DETAIL -
1 user registry handles leaked from \Registry\User\S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxx-1106: Process 3616 (\Device\HarddiskVolume1\Windows\System32\cmd.exe) has opened key \REGISTRY\USER\S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxx-1106 Event Xml: 1530 0 3 0 0 0x80000000000000 121 Application server.domain.tld
1 user registry handles leaked from \Registry\User\S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxx-1106: Process 3616 (\Device\HarddiskVolume1\Windows\System32\cmd.exe) has opened key \REGISTRY\USER\S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxx-1106
<:event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">


Some possible workarounds exists:

• Run scripts under "local system"
• Use the following workaround: remkoweijnen blogpost
• Insert a sleep inside the HP RDP job. This is the part where you configure which script will be executed. This is the content who gets copied to a file called rxscript.bat and thus executed. Note: for the sleepcommand: download the Windows 2003 resource kit tools.

Withouth elevation:


With elevation:


Other examples of UAC behaviour:
repadmin /showrepl (on a domain controller):


With elevation:


slmgr -dlv (show license information, determine which KMS server activated your server):


More on UAC: http://technet.microsoft.com/en-us/library/cc512679.aspx

Very recently I followed a question at activedir.org (very interesting mailing list!) concerning whether external trusts support Kerberos. (topic @ activedir.org)

Microsoft isn't always as clear about it, but the following articles does state it: Kerberos is only possible when a forest trust is created: http://technet.microsoft.com/nl-be/library/bb727065(en-us).aspx

And some other references:

• http://blogs.technet.com/tkarch/archive/2007/03/19/kerberos-demystified.aspx
  Access to resources between domains that are connected by an external trust requires Pre-Windows 2000 Compatibility. Because external trusts only support NTLM authentication, queries to a directory in a different forest are always handled as anonymous access.
• http://support.microsoft.com/kb/830576
  If you use an external trust NTLM is used as authentication protocol, no Kerberos involved. Kerberos authentication only works if the trust type is “Forest Trust”.
• http://support.microsoft.com/kb/905687
  External trusts only support Integrated Windows authentication (formerly called NTLM) for the user access.

Though this has changed for Windows 2008 SP2:

A KMS hosted on Windows Vista or Windows Server 2008 SP2 now counts virtual machines toward the activation threshold.

In other words, environments which mainly consists of VM's now have the ability to setup a KMS withouth having to use workarounds.

Source: http://download.microsoft.com/download/5/A/2/5A29FA34-4E89-45AF-AA4D-7A148E66039E/Volume%20Activation%20Changes%20for%20Service%20Pack%202%20for%20Windows%20Vista%20and%20Windows%20Server%202008.docx

Which provided the following solution:

certutil -setreg ca\setupstatus +512
net stop certsvc
net start certsvc

And now Microsoft issued KB967332 5 months after that post.

INFO  [RES] Network Name <vdmprinters>: Initiating the Network Name operation : 'Verifying computer object associated with network name resource printcluster'
INFO  [RES] Network Name <vdmprinters>: Trying to find computer account printcluster object GUID(b4a849281d4b47d30af3681b8590a20e) on any available domain controller.
INFO  [RES] Network Name <vdmprinters>: Found computer account printcluster on domain controller \dc1.domain.local.

Just a very interesting series of posts by Jorge on how the Active Directory clients determine which domain controller servers their logon request and which domain controller sends the GPO files over.

DC Locator process part 1
DC Locator process part 2
DC Locator process part 3

A small add-on: using start - run - cmd and execute "set" you can easily determine your logon server. Determining which DC sent the GPO's can be determined by running "gpresult /R" (Windows 2008) or "gpresult" (Vista)

The following Technet article is also a nice source of information: How DNS Support for Active Directory Works

[Update:] added NTP as said by Brent in the comments

The following post will explain how to let basic Active Directory related network traffic such as logon requests or replication traffic, be it either sysvol items or AD objects, happen through firewalls. This doesn't mean I'm totally in favour of implementing a firewall between every possible environment. But you might encounter projects where firewalls are used between different sites or just internally between clients and servers.  In that case you might find the following interesting:

The following list is an overview of the AD related services with their required ports:

• NetBIOS name service (137/tcp, 137/udp)


• NetBIOS datagram service (138/udp)


• NetBIOS session service (139/tcp)


• SMB over IP (Microsoft-DS)(445/tcp, 445/udp)


• LDAP (389/tcp)


• LDAP ping (389/udp)


• LDAP over SSL (636/tcp)


• Global catalog LDAP (3268/tcp)


• Global catalog LDAP over SSL (3269/tcp)


• Kerberos (88/tcp, 88/udp)


• DNS (53/tcp, 53/udp)


• WINS resolution (if required) (1512/tcp, 1512/udp)


• WINS replication (if required) (42/tcp, 42/udp)


• RPC endpoint mapper (135/tcp, 135/udp)


• AD replication (TCP 1024 - 65535*)


• FRS replication (TCP 1024 - 65535*)


• Netlogon (TCP 1024 - 65535*)


• NTP (123/udp)

It all seems fine but those last 3 entries are quit funny. If you ask your security guy to implement those, he might aswell just throw his firewall out of the window. Microsoft describes this situation as turning your firewall into swiss cheese (Technet: Active Directory Replication over Firewalls).  A second solution is to set up an IPsec tunnel. Something in between is the option to restrict certain RPC services to a specific port. There are a lot of services which use RPC to determine the port they are listening on. Domain replication, file replicaton, netlogon, remote eventviewer, remote computermanagement are all examples. Whenever such a service is started the "RPC end-point mapper", a service which listens on port 135, decides which port the service will actually listen on (between 1024 and 65535). This behaviour is nicely explained in the following posts over at the (Microsoft Networking Team: RPC Endpoint Mapper in a network trace and RPC to Go v.1)

By choosing those ports ourselves and fixing the services to listen on those port we can actually limit the required ports to be opened to 3 single ports:

• AD replication:

HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\Services\NTDS\Parameters\
DWORD: "TCP/IP Port"
value: port1

• Sysvol replicaton

HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\Services\NTFRS\Parameters\
DWORD: "RPC TCP/IP Port Assignment"
value: port2

• Netlogon traffic

HKEY_LOCAL_MACHINESYSTEM\CurrentControlSet\Services\Netlogon\Parameters\
DWORD: "DCTcpipPort"
value: port3

Don't forget: A reboot is required

Note: actually only sysvol and ad replication traffic is required for two domain controllers to talk across a firewall. The netlogon service is only required when you want to handle logon requests or domain joins accross a firewall. This might be the case when you're setting up a new site and at first you don't have that Domain Controller available to handle your requests.

Microsoft KB's which explain the given registry keys:

KB224196 and KB319553

The customer I'm currently working at has some c7000 enclosures with Insight Control licenses which gives us the ability to monitor the servers with the HP SIM Performance Management Pack. For a windows 2003 hosts the process is quit straightforward: license, configuring logging, monitoring and sample rate and after a while all is fine.

For all our Windows 2008 hosts I encountered the following problem: at the page where the currently selected target systems get analyzed, all Windows 2008 hosts appear as licensed but they are reported as "unsupported configurations". After double checking the PMP supported OS list, I found out Windows 2008 is fully supported. What bothered me was a counter in the upper left corner which stated that there were several unreachable licensed servers.

After googling I found the following ITRC post: Error unsupported configuration which led me to a solution. I generally dislike the idea of altering database content, but I even less liked the idea of having to change the system properties of each Windows 2008 SIM object. So I came up with the following solution: The PMP_V3_0 database contains a table dbo.supported_software which contains all currently supported OS' by PMP. There are several lines which describe all 2008 flavours, though the exact names slightly mismatched what HP SIM was reporting on the System Properties summary. I simply copied the rows and altered them as seen below on the screenshot:



I'm aware that this is the type of solution which might get broken by a PMP upgrade. But it sure made the HP PMP plugin work for all our Windows 2008 hosts.

Although we figured out the necessary steps to add a Windows 2008 failover cluster to HP SIM (currently version 5.2) in our build environment, for some reason this stopped working after some time.

The necessary steps to add a cluster are described below. At first sight some steps may seem unnecessary, but in the end this has proven to be successful. Skipping some of the steps resulted in nodes being discovered with the name of the cluster and vice versa.

Add both nodes

Run an identify task on those nodes in SIM

Restart the SNMP service on both nodes (it will also restart some HP dependent services)

Run an identify task on those nodes in SIM again

Add the virtual IP which is used to administer the cluster

After performing these steps a HP SIM object should be created which represents the cluster. It should look something like this:



On the other hand, if the call seems to time out and you receive something like this:



You might need to apply the following registry fix on all your nodes and redo the discovery process:



All credits go to "Karim H" over at HP ITRC forums: HP SIM: Cluster Monitor (ITRC Forums)

The project I'm currently working on involves a Windows 2008 (32-bit) failover cluster dedicated to printing. The print management console, introducted with Windows 2003 R2 has an export feature which is supposed to replace the printmig utility. I like the idea of having the possiblity to save multiple sets of drivers/ print queues to a file. It's an eassy way to have a roll-back plan when some new installed driver doesn't works the way it's supposed to be working. Besides the fact that some thirdy party printer drives don't install nicely on the virtual print cluster, there seems to be an issue with the export feature. The good news is that it will be fixed in SP2 of Windows 2008.



I noticed that even with drivers which are provided within Windows 2008, the issue exists. I simply added the HP Laserjet 4 printer driver to the drivers on the cluster:



Which is nicely installed without errors:



But when I want to save the drivers, print queues and ports:



The following error occurs:



When I click the event viewer button, no errors seem to have been logged:



And if I perform a manual export by using the printbrm.exe command line utility I receive the following error:



After using sysinternals process monitor I found out that the export utility is trying to access a share (c$) on the network name "clif01ps". This is actually the name of the printer resource, and because windows 2008 failover clusteirng uses scoped shares, the share isn't available at all at that path.

I opened a call for this at Microsoft who confirmed they could reproduce this issue. A month later a fix was deliverd which solved the problem for us. Microsoft support confirmed the fix will be included with Windows 2008 SP2.

Related forumpost: Microsoft Technet Forums

People working with HP RDP or the Smartstart Scripting toolkit probably know hponcfg. The HP Online Configuration utility. It can be used to configure the iLO interface of a server by means of XML files.
Mostly you can use it just from withing the OS running on the server. Lately I found out it is also provided as an option on the Onboard Administrator.

When opening a ssh (or telnet) session to the Onboard Administrator (the management interface of a c-class enclosure), the same tool is available. The advantage is that you can target all iLO interfaces at once.

It could be quit usefull when you forgot the password and want to reset it or just when you have no clue about the IP which was set either manually or by dhcp. It might be used to upgrade the firmware of all iLO's at once.


After setting up a ssh session, type help to receive an overview of the possible commands.

hponcfg ALL << * (press enter)
(paste iLO xml script)
* (press enter)

The "*" is actually a marker which should not be used in the pasted xml script. It's a way to show the command where the script begins and ends.

Sample scripts:

Delete HP SIM trust

<RIBCL VERSION="2.0">
  <LOGIN USER_LOGIN="adminname" PASSWORD="password">
    <SSO_INFO MODE="write">
      <DELETE_SERVER INDEX="0" />
    </SSO_INFO>
  </LOGIN>
</RIBCL>

Configure Active Directory integration

<RIBCL version = "2.0">
   <LOGIN USER_LOGIN="Administrator" PASSWORD=" ">
   <DIR_INFO MODE="write">
    <MOD_DIR_CONFIG>
      <DIR_AUTHENTICATION_ENABLED VALUE = "Y"/>
      <DIR_LOCAL_USER_ACCT VALUE = "Y"/>
      <DIR_SERVER_ADDRESS VALUE = "domain.local"/>
      <DIR_SERVER_PORT VALUE = "636"/>
      <DIR_OBJECT_DN VALUE = ""/>
      <DIR_OBJECT_PASSWORD VALUE = ""/>
      <DIR_USER_CONTEXT_1 VALUE = "@domain.local"/>
      <DIR_USER_CONTEXT_2 VALUE = "OU=Server Admins,OU=Users,OU=site,DC=domain,DC=local"/>
      <DIR_USER_CONTEXT_3 VALUE = ""/>
   <DIR_ENABLE_GRP_ACCT value = "yes"/>
   <DIR_GRPACCT1_NAME value = "CN=IloAdmins,OU=Security,OU=Groups,OU=site,DC=domain,DC=local"/>
   <DIR_GRPACCT1_PRIV value = "1,2,3,4,5"/>
    </MOD_DIR_CONFIG>
      </DIR_INFO>
 </LOGIN>
</RIBCL>

Configure HP SIM and trust by certificate to enable SSO

<RIBCL version = "2.0">
<LOGIN USER_LOGIN="Administrator" PASSWORD=" ">
<SSO_INFO MODE="write">
<MOD_SSO_SETTINGS>
<TRUST_MODE VALUE="CERTIFICATE" />
</MOD_SSO_SETTINGS>
<!-- Add an SSO server record using indirect iLO import from -->
<!-- the network name. -->
<SSO_SERVER IMPORT_FROM="192.168.10.11" />
</SSO_INFO>
</LOGIN>
</RIBCL>

Other iLO XML sample scripts can be found at: HP.com

Another usefull command available at the Onboard Administrator is the "reset" command. You can use it like this reset server 4. In this case the command would temporary remove all power from blade 4. This can be usefull when the iLO is all locked up. It saves you a walk to the datacenter.

"setspn -A http/web server01"
"setspn -A http/web.domain.local server01"

Create an AD user for kerberos delegation:

Create a dedicated user for this

Make sure to check trust for delegation on the user properties in aduc

Make this user member of the IIS_IUSR group on IIS nodes

Use this user as identity for the application pool used by the website

Add the spn's to the user AD account:  setspn -a http/nlbweb ADuser  setspn -a http/nlbweb.domain.local ADuser  Verify with setspn -l ADuser

Configuring the authentication on the IIS nodes:

open applicationhost.conf (c:\windows\system32\inetsrv\config\)

Locate the website you wish to configure

search something like <windowsAuthentication enabled="true" useKernelMode="true" />

change it to include useAppPoolCredentials="true": <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />

And most important: configure the browser or the client

Add the URL to the local intranet zone (nlbweb and/or nlbweb.domain.local)

Enable windows integrated authtentication on the advanced tab (default is enabled)

Automatic logon only in intranet zone (default setting) (or even less restrictive: automatic logon with current username and password)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Registry Value: LogLevel
Value Type: REG_DWORD
Value Data: 0x1
 
Sources:

Rakkimk: Enabling Kerberos Delegation on a NLB scenario

Ken Schaefer: New in IIS 7 - Kernel Mode Authentication

Care, Share and Grow!: Kerberos troubleshooting from IIS perspective

Microsoft.com: kb 262177 (enbable kerberos logging)

Determing whether your application suffers of this phenomena is quit eassy: use the latest version of the sysinternals process monitor which has a built-in network trace. (Process Monitor)

The following are example console who suffer from this: Microsoft SQL management, Exchange 2007 management and Citrix Xenapp management console.
Unchecking both settings in the advanced section of your IE browser will solve the slow startup:

The catch here is that the webenrollment part of the Windows 2008 AD CS only can handle v1 or v2 templates. So if you choose "Windows 2008" template when duplicating your template, you will only be able to use it for auto-enrollment purposes or enrollment by the mmc. It will not appear on the certsrv website.

Source: http://blogs.technet.com/ad/archive/2008/06/30/2008-web-enrollment-and-version-3-templates.aspx

When you duplicate a template in orde to change settings like the validity period, the template becomes a version 2 (Windows 2003 ) or a version 3 (Windows 2008 ) certificate. The out of the box provided certificates are version 1 certificates.