“While processing a TGS request for the target server %1, the account %2 did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of %3). The requested etypes were %4. The accounts available etypes were %5.”

To resolve this issue you need to make the Group Policy change to allow DES encryption for Kerberos authentication on the DCs, documented in this KB http://support.microsoft.com/kb/977321.

1. In the Group Policy Management Console (GPMC), locate the following location:
   Computer Configuration\ Windows Settings\ Security Settings\ Local Policies\ Security Options
2. Click to select the Network security: Configure encryption types allowed for Kerberos option.
3. Click to select Define these policy settings and all the six check boxes for the encryption types.
4. Click OK. Close the GPMC.

To be able to make this change, you need to have first installed the following hotfix, http://support.microsoft.com/kb/978055 . This fix is included in Windows Server 2008 R2 SP1, so if you have installed that you are already good to go.

A good discussion of this issue and further steps you may need to take with service accounts can be found here:

http://social.technet.microsoft.com/Forums/en-US/winserversecurity/thread/ecf15eb9-26cf-483b-b1e3-1b1c7e4901e8/

adprep /forestprep

you get the following result, “adprep.exe is valid, but if for a machine type other than the current machine.”:

An alternative is to try running it from a 64-bit machine that is not a DC, but then you discover that this process absolutely must be run from a DC:

So what do you do? The answer is that you run adprep32.exe, a 32-bit version of adprep, which is included in the same folder:

adprep32 /forestprep

The below script will generate you a report listing all users whose Display Name matches that of somebody else and for instance what a new Display Name would look like if you added their department field in brackets after their name – of course you could use another field entirely to distinguish them.

Note: that it is using the Quest AD cmdlets.

Add-PSSnapin -Name Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue

$users = Get-QADUser -DontUseDefaultIncludedProperties -SizeLimit 0 -LdapFilter '(mail=*)' | Group-Object displayname | Where-Object {$_.count -gt 1}
$myCol = @()

foreach ($user in $users){

    foreach ($duplicateuser in $user.group){

    $NewDisplayName = $duplicateuser.DisplayName + " (" + $duplicateuser.Department + ")"

    $MYInfo = “” | Select-Object UserID,CurrentDisplayName,newDisplayName,Department
    $MYInfo.UserID = $duplicateuser.Name
    $MYInfo.CurrentDisplayName = $duplicateuser.DisplayName
    $MYInfo.NewDisplayName = $NewDisplayName
    $MYInfo.Department = $duplicateuser.Department
    $myCol += $MYInfo
   }
}

$myCol | Export-Csv C:\Scripts\Report.csv -NoTypeInformation

After reviewing the report and deciding to fix everyone on the list you could do it with the very similar code below:

Add-PSSnapin -Name Quest.ActiveRoles.ADManagement -ErrorAction SilentlyContinue

$users = Get-QADUser -DontUseDefaultIncludedProperties -SizeLimit 0 -LdapFilter '(mail=*)' | Group-Object displayname | Where-Object {$_.count -gt 1}

foreach ($user in $users){

    foreach ($duplicateuser in $user.group){

    $NewDisplayName = $duplicateuser.DisplayName + " (" + $duplicateuser.Department + ")"
    Set-QADUser $duplicateuser -DisplayName $NewDisplayName

   }
}

Of course you might be in a scenario where some people already have brackets after their name and you wish to create a report of those. The below one liner will give you those results.

Get-QADUser -ldapfilter '(&(displayname=*(*)*)(mail=*))' -DontUseDefaultIncludedProperties | Select-Object name,displayname,department | Export-Csv C:\Scripts\Report.csv -NoTypeInformation

The first event will take place on Tuesday 26th Jan 2010 7.30pm GMT. We will be looking at the Windows 2008 R2 cmdlets and provider for Active Directory.

Sign up details are available on Richard Siddaway’s blog.

The second event will take place on Tuesday 9th Feb 2010 7.30pm GMT. We will be looking at WMI and WQL.

Details again on Richard Siddaway’s blog.

Mr Anonymous (it wasn’t me) has already posted a very nice comment which sums up part of the new management experience;

“cd AD:” = wow!

(OK I know you could do this already with the PowerShell community extensions, so it might not be wow for everybody)

I’ve been spending a lot of time recently checking out the PowerShell cmdlets for Active Directory in Windows Server 2008 R2 and they have also recently been made available for downlevel versions of Windows Server. I figured it would be handy to have a similar type Quick Reference Guide for these Active Directory cmdlets so I put  the AD PowerShell Quick Reference Guide together.

Hope you find it useful.

So I have spent some time checking it out which has resulted in my latest article on the Simple-Talk.com website being based on it, hope you find it useful.

Last week  I needed to create hundreds of distribution lists in Active Directory (using PowerShell of course ), some with particularly long names and during the first run through in my test environment about 20% of them failed to create with an error along the lines that one of the properties I was trying to set was causing a violation.

I tracked it down to the ldap ‘name’ property, i.e. the Relative Distinguished Name, and it appeared to have a limit of 64 characters although I could not confirm this with the AD documentation I found on MSDN.

Thankfully Twitter again proved incredibly useful, I posted my question on there and within minutes had a response from AD guru and PowerShell MVP Brandon Shell (I kind of hoped he would know when I posted the tweet), thanks to him again for his assistance. He encouraged me to post to a newsgroup and not too long after also followed up with the confirmed answer, links below:

http://technet.microsoft.com/en-us/library/cc977992.aspx

http://groups.google.com/group/microsoft.public.windows.server.active_directory/browse_thread/thread/d70df4342f43b8f7

First up we have the VMware user group in London on Thursday May 14th. This is an excellent event for VMware administrators to attend and has a great mix of vendor and community contributions. In particular this time check out Alan Renouf’s pre-show PowerShell workshop. This is before the usual start time and should be great if you are new to PowerShell or already using the VI Toolkit.

Sign up details are here.

Next up is the PowerShell user group at Microsoft in Reading on Tuesday 19th May. This time we have a real treat in store, PowerShell MVP Dmitry Sotnikov from Quest will be stopping by on his whistle stop tour of the UK to tell us about PowerGUI and the AD cmdlets, in particular recent updates. This was a great event when he presented for us last year and is a real opportunity if you use either of these products to get your questions answered or put forward any suggestions for improvements. You also get to meet a really cool guy and see if he manages to blue screen his machine again during a PowerShell demo by stopping all the services, having forgot to use the ‘whatif’ paramter! (I told him I’d get him back for making fun of me when I interviewed him for the Get-Scripting podcast)

Sign up details are here. You need to contact Richard if you wish to attend in person.

Finally on Thursday 28th May the Windows Server and Vista Squad user groups join the Active Directory user group for a joint Windows 7 event. Full content is yet to be confirmed, but that’s the first Windows 7 event I’ve heard of in this country.

Full details here.

Hope to see you at one of these events.

A month or so ago at a UK Technet event I saw James O’Neill carry out a demo of the AD cmdlets which will ship as part of Windows Server 2008 R2. They looked so good I had to check them out straight away and downloaded the beta of Server 2008 R2. I was so impressed I ended up changing what I was originally intending to present for March’s UK Powershell UserGroup so that I could share with people the good stuff that is coming. If you currently use Powershell to manage AD (or even if you are just using the curent GUI tools) you should definitely start checking these cmdlets out so are you a ready to take advantage of them as soon as possible. The best place to currently find out information about them is the Active Directory Powershell Blog – Pipelining AD One Object at a Time . There is some great info here on what is currently available and the direction it is headed.

I’ll give you a tip to help getting started with the cmdlets since some of the inline help is slightly behind the development of the cmdlets. There is a cmdlet for managing user accounts, Get-ADUser, which returns about 10 properties for a user account by default. (Note Quest regulars this is a fair bit less than what you have been used to). There is a parameter ‘-properties’ which you can use to specify particular attributes for a user account or all of them in one go. The inline help says you should use ‘-properties extended’ or’ -properties all’ to retrieve more than the default set. However, trying this out in the beta causes an error and fails to return anything for the user account.

Since the AD blog previously mentioned has a contact form I thought I would drop them a quick note about this and was pleased to receive a very prompt reponse from one of the developers that they had changed the format to be ‘-properties *’, but hadn’t updated the help in time for the beta release. So you would use something like this:

Get-ADUser username -Properties *

Easy when you know how

Finally for now, another way you can find out more information about the AD cmdlets is by listening to a recent episode of the PowerScripting podcast which featured PowerShell MVP Brandon Shell who is an expert at scripting around AD, has recently spent some time with the AD team and helped point them in the right direction for what we want to get out of these cmdlets.