Archive: Author Archive

RpcSs expected value WIN32_SHARE_PROCESS

2 comments February 12th, 2011

If you have a domain with a mixture of Win2003 and Win2008 domain controllers, you might get some ”false-positive” errors running DCDIAG.exe.

Starting test: Services
      Invalid service type: RpcSs on DC-Win2003, current value
      WIN32_OWN_PROCESS, expected value WIN32_SHARE_PROCESS
......................... DC-Win2003 failed test Services

If you run DCDIAG from a Win2003 DC it will not report any errors, but if you run it from a Win2008 DC it will report this error.

I.e. from a Win2008 DC:

Dcdiag /e (testing all DCs in the domain)


Dcdiag /s:DC-Win2003 /test:services (run test only against DC-Win2003).

If you look at the service on a Win2003 DC, its Type is 0x10 (own), while on a Win2008 DC its 0x20 (shared).


So when you run DCDIAG from a Win2008 DC it assumes the Type should be 0x20 on all DCs it runs a diagnostic on. The DCDIAG version on Win2008 will not check if it’s testing against a Win2003 DC.

If you try to change how this service runs on a Win2003 DC with: ”sc config rpcss type= share”, it will change the Type to 0x20 and a DCDIAG (/e) will be clean.

I had to ask the MS DS team about this, since there ain’t a KB regarding this and they made a KB regarding this issue. If you google it you will get various recomendations to change the RpcSs service to run as shared. The DS team said this is expected behavior from DCDIAG. You should NOT change the way this service run on a Win2003 DC. Leave it as it is, as it will not share its memory space of the instance of svchost with anyone (nobody is requesting to share the space). Even if you change it to shared.



No comments February 5th, 2011

If you’re going to prepare your domain/forest for 2008/2008R2 domain controllers, you’ve to run ADPREP before you can promote them. If your existing domain consists of 32-bits 2003 DC’s, you have to run the 32-bit version of ADPREP, named adprep32.exe.

Let’s say you have 3 domains in your forest and you want to raise the Forest Functional Level (FFL) and Domain Functional Level (DFL) to 2008R2.

1. Verify replication health (important):

The first thing you have to make sure of is that your replication is working. To get a quick forest wide overview, you can use a tool called repadmin.exe. (run it from cmd)

repadmin /replsum * /bysrc /bydest /sort:delta

Look at the output and if all DC’s shows “Fails” = 0, you’re ready to move on. If it report errors, you have to look into those before proceeding.

2. Extend the schema:

Log into the DC holding the Schema Master. If you don’t know who that is, run “netdom query fsmo” from any DC. Have the 2008R2 media reachable from the Schema Master.

If the Schema Master DC is a 2003 32-bit run:

adprep32 /forestprep

If you want to be 100 per cents sure that the extensions are replicated to all DC’s before move on to the next step:

Open ADSIedit.msc and navigate to:

Schema > (Properties on) “CN=Schema,CN=Configuration,DC=domain,DC=com

Check “objectVersion” value. Value should be “47” if it has replicated.

Also verify this on the PDCe DC in the other domains. If the value is “30” (2003 level), the change has not been replicated yet. To trigger a replication:

On the PDCe DC: “repadmin /syncall /A /P /e”

When all DC’s got the correct value you can;

 3.  Prepare the domain:

Run “adprep32 /domainprep” on each DC holding the Infrastructure Master (IM) FSMO. One IM in each domain. If you don’t plan to add 2008 DC’s to i.e. Domain C, you don’t have to run this on the IM in Domain C.

 4. If you have a Windows 2000 domain, you have to run:

“adprep32 /domainprep /gpprep”

It will not hurt to run this on a 2003 domain, as you can run the adpreps so many times you want.

5. RODC’s

If you plan to apply RODC’s into your domain, run:

“adprep32 /rodcprep”

 If you’ll never add RODC’s you can skip this, but DCDIAG will report an error regarding “NCSecDesc”. You can ignore the error, but who likes to do that?

FAQ’s and common errors regarding ADPREP from the Technet Wiki:

Published application launching full screen

No comments January 26th, 2011

We had a problem with some 2008 R2 terminal servers (RDS) with XenApp 6.0 installed on top. When a new user started a published application for the first time, the user got lunched into a full screen session. The “funny” thing was that this didn’t happened to all new users. It was just a random issue.

Nothing was logged in the event log, so we tried almost anything to figure out what caused this.

We were about to move many users over from 2003 terminal servers, so this was going to be a huge problem. We had read about the bug regarding roaming profile folders that already existed, and you tried to change i.e. “Start the following program at startup”, the change was not applied.

In lack of ideas we installed the hotfix on all the domain controllers (2008 R1) and the RDS servers. Guess what, that fixed the random problem launching some users into full screen.

I can’t wait for the release of SP1 for 2008 R2!

You can request the hotfix here.

Do I need WINS?

No comments December 15th, 2010

No, you do not!


  • You have Exchange 2000/2003 and want to preserve full functionality. Changing a domain password with OWA 2003, export/import with Exmerge and Outlook clients prior to 2003, all requires WINS.
  • You have a large sub netted network, NETBIOS broadcast may not work between the networks.
  • You have a program that requires WINS.

I assume you don’t have any NT servers or Win98 clients 🙂 

If you do have a WINS server in play, you could use “Performance Monitor” to monitor WINS queries (“Successful Queries/sec”).


If you have a lot of queries, you should take into consideration if NETBIOS name query broadcasts are acceptable. Just take into mind that broadcasts will increase the load on your network.


Checking AD Replication

2 comments November 29th, 2010

When you have multiple domain controllers they need to replicate since they are multi-masters. DC1 should hold the same data as DC2 and vice versa, and changes can be done on the DC that suits you (in theory).

If you want to have a quick look if the replication in your forest is ok, you can use a powerful command line tool called “repadmin”.

Open cmd and run: repadmin /replsum

If “largest delta” is less than 1 hour (intrasite) and “fails” = 0, your AD replication (not testing FRS replication) between all DCs in the forest is good.

If fails > 0 you need to investigate further.

Replication is based on pull, so you should focus on “Destination DSA” and “Inbound Neighbors”.

If DC01Test had some failures, I would run: “repadmin /showrepl dc01test” to see which DC(s) it can’t pull changes from, or if it’s a single Naming Context or all NC’s that it has problem replicating. Replication is 100% dependent of DNS, so DNS is a common cause of replication problems.


The five dots says I have 2 domain controllers in the forest. The first three dots are “processing dots”, while each of the rest represent a DC. 5 – 3 = 2 domain controllers.

Largest Delta: longest replication gap amongst all replication links for a particular DC

A. DC01Test Largest Delta: 47m:15s
B. Last attempt: 19:57:13 (from showrepl, where DC01test pulled schema changes from DC4test)

A + B = Rep. Summary Start Time: 20:44:28


Inbound Neighbors: Shows the DC’s <source DC> is pulling from and the 4 NC’s (5 links).

DSA Object GUID: The GUID of the source or destination. A CNAME named GUID located in the _msdcs domain zone must be present and have a value of the hostname of the correct DC.

Last attempt @: last time DC01Test pulled from DC4Test and if it was successful.

If you want to read more about what repadmin can do, you can download the whitepaper:

Traces of the old domain name after a rename

No comments November 7th, 2010

When you have renamed a domain there will be some registry keys left with the old domain name under HKLM\System\CCS\Services\NTDS\Parameters

Name: “Configuration NC”
Type: reg_sz
Value: CN=Configuration,DC=oldname,DC=com

Name: “Machine DN Name”
Type: reg_sz
Value: CN=NTDS Settings,……,CN=Configuration,DC=oldname,DC=com

Name: “Src Srv objectGuid”
Type: reg_binary
Value: <some_DC>

Those keys where created by LSASS.exe when the DC was created with DCPROMO. Rendom.exe will not modify them. They are not vital and are not in use. You can update those keys for consistency if you like.

Credit to Ned Pyle at AskDS for the information.

Documenting AD groups

1 comment October 29th, 2010

AD Group membership should be documented, but there are none good built-in MS tools that can do it for you (atleast that I’m aware of). You can use tools such as “dsget group” but you can’t pipe it to Excel and get it user/customer friendly 😐

Here is a script that will do the job for you. It requires that you have Excel installed.
If you don’t have Excel, it will work on a trial version that you’ll find here.

'------------------Save me as .vbs ----------------------------------------------
' The script searces for all AD groups (as you can specify) and writes
' the group name with the group manager and its members to an Excel spred sheet.
' One sheet per group.
' Privilages to run: "domain users"
' v.1.1
' rsoe(a)
On Error Resume Next
Const MyDomain = "dc=spurs,dc=local"
' If you don't want all built-in groups but only groups in a spesific OU:
' Const MyDomain = "ou=ChildOU,ou=ParentOU,dc=spurs,dc=local"
Const E_ADS_PROPERTY_NOT_FOUND  = &h8000500D
Set objConnection = CreateObject("ADODB.Connection")
Set objCommand =   CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOObject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection
objCommand.Properties("Page Size") = 1000
objCommand.Properties("Searchscope") = ADS_SCOPE_SUBTREE
' Open Excel for writing
Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = True
' Find all groups
objCommand.CommandText = _
    "SELECT ADsPath, Name FROM 'LDAP://" & MyDomain & "' WHERE objectCategory='group'"
Set objRecordSet = objCommand.Execute
Do Until objRecordSet.EOF
    Set objGroup = GetObject(objRecordSet.Fields("ADsPath").Value)
 strGroupName = objRecordSet.Fields("Name").Value

 ' Find if the group has a manager
 strManagedBy = objGroup.Get("managedBy")
 If IsEmpty(strManagedBy) = FALSE Then
       strManager = strManagedBy  
    Else strManager = "-"
    End If
 ' Give the sheet the Group name. One sheet per group.
 objExcel.Sheets.Add.Name = strGroupName

 arrMemberOf = objGroup.GetEx("member")
 objExcel.Cells(1, 1).Value = "Members of " & strGroupName & ":"
 objExcel.Cells(2, 1).Value = "Managed by: " & strManager
 i = 3
 count = 0
    ' Check to see if the group contains users
 If Err.Number <> E_ADS_PROPERTY_NOT_FOUND then
    For Each strMemberOf in arrMemberOf
          Set objMember = GetObject("LDAP://" & strMemberOf)
       strMemberName = right(objMember.Name,len(objMember.Name)-3)
       objExcel.Cells(i, 1).Value = strMemberName
       set objMember = nothing
       i = i + 1
       count = count + 1
    objExcel.Cells(i, 1).Value = "Member count: " & count
       ' The group don't have any members
    objExcel.Cells(i, 1).Value = "Member count: " & count
 End If

 i = 0
 count = 0
 strManagedBy = ""
 Set objGroup = nothing

The perfect excuse to buy an iPhone 4

No comments October 28th, 2010

Most of the phone calls the AD service desk receives are about user accounts that have been disabled or forgotten passwords.
This is a small task to handle if you have a task pad of ADUC in front of you.

It’s Saturday and you are watching a Tottenham game with a fellow Spurs fan at his place. You receive a call from your boss that has forgotten his AD password. He tells you reset his password *now*! 

Your friend doesn’t have an Internet connection, so you have to get down to the office to reset his bloody password. Arrrgg! 

I just bought an iPhone 4 and downloaded an app called “AD Helpdesk”. If you have one, you can watch the game and please your boss at the same time.

Setup a VPN connection on the phone to reach your internal network and start the App.

Search AD for his username and just reset his password from the app.

More about the app:

Entourage 2008 autodiscover

1 comment September 28th, 2010

This is not an Active Directory entry, so I’ll tag it with “nothing” 🙂

We have been living happily in an environment with a fully patched Exchange 2007 organization and Outlook 2007/2010 clients. Autodiscover working like a charm using SRV-records for redirection. The joy suddenly stopped when a client had bought a Mac with “Entourage 2008”.

We knew that the autodiscover worked on Mac’s bundled mail client “Mail”, so it was out of the question that a Microsoft product like Entourage 2008 wouldn’t work.

How wrong could I be… I updated the Entourage with the latest patches, but it didn’t want to connect to the Exchange (CAS) through an ISA server.

Entourage 2004 used WebDAV, but 2008 should use EWS. I googled around and found on some forums that Entourage didn’t support SRV-records for autodiscover. BAH!

After further searching I got a track of “Entourage 2008, Web Services Edition”. I downloaded it and got it installed.


It connected to the mailbox without issues using autodiscover. I didn’t have to modify the “Outlook Anywhere”  ISA rule as the /ews/* path already was set. The EWS directory on the CAS was left with default values.

You’ll find the Web Services Edition here.


1 comment August 4th, 2010

A colleague of mine showed me his blog and how cool WordPress was, so I got carried away and moved my blog.

When he saw what I was blogging about, he said I now officialy was a 200% N.E.R.D. (jeeez what a nitwit he is).