Zoho Banner September 2011

Archive for the ‘Windows Server 2008’ Category

Some time ago I blogged about the Acctinfo2.dll tool and how unfortunate it was that a 64-bit version was not available.  Well, the good news is that you can now download a 64-bit version from here:

 Acctinfo2_64bit.zip

I have tested the DLL on both Windows Server 2008 and Windows Server 2008 R2 and it seems to work well.  However, please note this version is completely unsupported!  Download at use entirely at your own risk.

Tony

If you’re creating contact objects in Active Directory the Exchange cmdlets New-MailContact, Set-MailContact and Set-Contact are usually sufficient.  On the other hand I haven’t found a way using these cmdlets to set all the attributes that I might need.  For example, the “description” attribute doesn’t appear to feature anywhere.

Things have obviously changed with the AD Powershell Provider and associated cmdlets in Windows Server 2008 R2, but here’s a script to bulk create contacts  from CSV file if you’re still using Powershell 1.0.

The format of the requried CSV file looks like this:

givenName,sn,displayName,mail,description
Bob,Smith,”Bob Smith”,bob.smith@gmail.com,”External Supplier”
Sue,Jones,”Sue Jones”,sue.jones@hotmail.com,”Hadware Sales”
Graeme,Turner,”Graeme Turner”,graeme.turner@yahoo.com,partner

#########################################################
#
# Name: BulkCreateContacts.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 13/12/2009
# Comment: PowerShell 1.0 script to
# bulk create AD Contact objects from csv file
#
#########################################################

# Set the target OU where the contacts will be created
$ContactOU=[ADSI]“LDAP://ou=Contacts,dc=mycompany,dc=com“

# Find our current working directory
$working = $(Get-Location)

# Specify the folder and CSV file to use
$folder = “C:\util\Powershell\CSV”
Set-Location $folder
$csv = Import-Csv “contacts.csv”

# Parse the CSV file line by line
foreach($line in $csv) {

# Assign variables to each attribute
$givenName = $line.givenName
$sn = $line.sn
$displayName = $line.displayName
$mail = $line.mail
$description = $line.description
$targetAddress = $line.mail

# Go ahead and create the contact object
$Contact = $ContactOU.create(“Contact”,”cn=$displayName”)
# Set the attributes on the contact object
$Contact.Put(“givenName”,$givenName)
$Contact.put(“sn”,$sn)
$Contact.put(“displayName”,$displayName)
$Contact.put(“mail”,$mail)
$Contact.put(“description”,$description)
$Contact.put(“targetAddress”,$targetAddress)
# Commit the changes
$Contact.setinfo()
# Mail-enable the contact (if you need to)
Enable-MailContact -Identity $displayName -ExternalEmailAddress $targetAddress
}
# Go back to the original working directory
Set-Location $working

The other day I applied Update Rollup 1 for Exchange Server 2007 Service Pack 2 in my test lab and wanted to check that the update was successfully applied.  Being something of a Powershell fan I first tried the command shown below:

(get-exchangeserver MyE2K7Server).admindisplayversion

The output showed Version 8.2 (Build 176.2), which is the same as Exchange Server 2007 SP2 without the Update Rollup.  Next I look at the value using the Exchange Management Console (EMC), which showed me the same information.

Sp2

I even checked the registry under HKLM\SOFTWARE\Microsoft\Exchange\v8.0\<role> and the ConfiguredVersion value shows the same (8.2.176.2).

The only place I noticed the build number had been incremented was in the EMC under Help->About.

After some Googling I found the statement below from Microsoft’s Ananth Ramanathan

Successful installation of an update rollup should not be ascertained by the version number shown in the admin tools. The version number displayed by Exchange Management Console or other administrative mechanisms is obtained from the Exchange Server Object in Active Directory. If we update the Exchange Server Object in Active Directory to show a new version number for every rollup, it would require additional privileges for the account being used to install the rollup. Since many large customers have split level administrative model where the Exchange administrators do not have permissions to the Active Directory we do not update the Active Directory with an updated version number when the rollup is installed.

Another factor is that the rollup is no different than a Hotfix/Update for other products from Microsoft. So as an administrator you should do what you usually do for validating that the Hotfix is correctly installed/ In Windows Server 2003, you will need to go to Add//Remove programs in control panel and make sure the “Show Updates” checkbox is selected at the top. In Windows Server 2008, you will need to go to “View Installed Updates” in the Control Panel.

Ananth’s method is fine you want to look at one Exchange Server, but what if you want to list the build levels for all Exchange servers in your organisation?  Powershell to the rescue!  Here’s a script I put together to show the names, editions and build numbers for each Exchange server in the organisation.

#########################################################
#
# Name: GetExchangeBuild.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 24/11/2009
# Comment: PowerShell script to list build info
# for each Exchange Server in the organisation
#
#########################################################

#Uncomment the line below if running from Powershell outside the EMS
#add-pssnapin Microsoft.Exchange.Management.Powershell.Admin

$exsrvs = (get-exchangeserver)
foreach ($exsrv in $exsrvs)
{
$version = (get-exchangeserver -identity $exsrv).admindisplayversion
$edition = (get-exchangeserver -identity $exsrv).edition
write-host “=====================================================”
write-host “Exchange Server: $exsrv”
write-host $version
write-host “Edition: $edition”
write-host “Installed Update Rollups:”
$baseKey = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey(‘LocalMachine’, $exsrv)
$regKey = “SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products\461C2B4266EDEF444B864AD6D9E5B613\Patches\”
$baseKey = $baseKey.OpenSubKey($regKey)
$Updates = $baseKey.GetSubKeyNames()
ForEach($Update in $Updates)
{
$fullPath= $regKey + $Update
$UpdateKey = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey(‘LocalMachine’, $exsrv)
$UpdateKey = $UpdateKey.OpenSubKey($fullPath)
$values = $UpdateKey.GetValueNames()
ForEach($value in $values)
{
if ($value -eq “DisplayName”)
{Write-host $UpdateKey.GetValue($value)}
}
}
write-host “=====================================================”
}

Let me know if you have any problems with the script, or if you can think of ways to improve it.

Tony

Windows Server 2008 R2 introduces the ability to revert to an earlier forest or domain functional level.  Previous versions of Active Directory did not have this ability and raising the forest or domain function level was, effectively, a one-way operation.  I say “effectively” because it is possible to revert, but only through highly disruptive recovery operations (full forest recovery in the case of a forest functional level upgrade).

I’ve actually not experienced or even heard of anyone having serious problems following a functional level upgrade, but that’s not really the point.  Have you ever tried to get approval from a Change Manager when your proposed backout plan involves a full forest outage of 12 hours or more?  In providing a mechanism for reversing a functional level upgrade, Microsoft has responded to customer demand for peace of mind, rather than a fix for a known problem.

This article shows how to raise the forest functional level and then revert it using Powershell commands.  The screenshots shown below are from running the commands in Powershell ISE.

On a Domain Controller, open a Powershell prompt and (assuming you don’t already have it) import the Active Directory Powershell module.

Import-module ActiveDirectory

Show the current Domain Functional Level

get-addomain | format-list domainmode

get-domain-mode-1.jpg

Show the current Forest Functional Level

get-adforest | format-list forestmode

get-forest-mode-1.jpg

Set the Forest Functional Level to Windows 2008 R2 (Forest Functional Level 4)

set-adforestmode -identity ad.contoso.com -forestmode windows2008R2forest

Show the current Forest Functional Level

get-adforest | format-list forestmode

get-forest-mode-2.jpg

Revert the Forest Functional Level to Windows 2008 (Forest Functional Level 3)

set-adforestmode -identity ad.contoso.com -forestmode windows2008forest

Show the current Forest Functional Level

get-adforest | format-list forestmode

You should see that the functional level has reverted successfully.

Note that after raising the functional level certain subsequent operations prevent you from reverting.  One of these operations is enabling the AD Recycle Bin, as shown below.

Enable-ADOptionalFeature 'Recycle Bin Feature' -Scope ForestOrConfigurationSet -Target ad.contoso.com

After enabling the AD Recycle Bin you will receive the error below if you try to revert the functional level.

attempt-to-revert-after-enabling-recycle-bin.jpg

Another limitation is that you can currently only revert from Windows Server 2008 R2 functional level to Windows Server 2008 functional level.  In other words, the feature has not be retro-fitted to support earlier functional levels.

As you can see, raising and reverting the functional level is fairly straightforward operation once you have the appropriate Powershell commands.  It should give you (and your Change Manager)  a degree of comfort when planning your upgrade. :-)

I went to install the AD Management Gateway Service (KB968934) on a Domain Controller running Windows Server 2008 SP2 and I received the error shown below.

KB968934_Error

Installer encountered an error: 0x80070422.  The service cannot be started, either because it is disabled or because it has not enabled devices associated with it.

The problem was that the Windows Update service had been set to Disabled by Group Policy on the DC.  After enabling the service (temporarily) the msu package installed ok.

Kind of obvious really, but it had me guessing for a while.

There seems to be a certain amount of confusion surrounding Domain and Forest functional levels.  Microsoft’s own documentation doesn’t always incorporate the latest version information.  KB322692 is a case in point.  I also often hear the words “Native” and “Mixed” in relation to functional levels involving Windows Server 2003 or 2008, when in fact these terms are only relevant in the context of Windows 2000 Server.  Anyway, in an effort to clarify the situation and to avoid confusion I put together the tables below. 

  

Domain Functional Level

Numeric

DCs Supported
Windows 2000 Mixed

0

Windows NT 4.0
Windows 2000 Server
Windows Server 2003
Windows 2000 Native

0

Windows Server 2000
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2003 Interim

1

Windows NT 4.0
Windows Server 2003
Windows Server 2003

2

Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2008

3

Windows Server 2008
Windows Server 2008 R2
Windows Server 2008 R2

4

Windows Server 2008 R2

 

Forest Functional Level

Numeric

DCs Supported
Windows 2000

0

Windows NT 4.0
Windows Server 2000
Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2003 Interim

1

Windows NT 4.0
Windows Server 2003
Windows Server 2003

2

Windows Server 2003
Windows Server 2008
Windows Server 2008 R2
Windows Server 2008

3

Windows Server 2008
Windows Server 2008 R2
Windows Server 2008 R2

4

Windows Server 2008 R2

Earlier this week Nathan Mercer (Technology Advisor for Microsoft) gave me a brief look at the new Powershell Integrated Scripting Environment available with Windows Server 2008 R2.  ISE allows you to run commands and write, test, and debug scripts in a Windows GUI.  It also has multi-line editing, tab completion, syntax coloring, selective execution and context-sensitive help.  The best thing about it from my perspective is that it is great for demos of R2 Active Directory Powershell cmdlets.  Basically, it provides a much nicer view than the powershell command line and the selective execution allows you to pre-load all the commands you need (and save them in a Powershell data file), so that you don’t have to type them in front of a whole bunch of people! 

Powershell ISE

ISE is installed as a feature.  You can use server manager to install ISE, but if you want to go the Powershell route, try the following commands:

> Import-module ServerManager

> Add-WindowsFeature Powershell-ise

To use the feature and launch the GUI simply type the following at the Powershell command prompt:

> ise

Enjoy!

Wow, looking at the site I see that I haven’t been blogging for the past two months.  I have a good excuse – I was away for 5 weeks on holiday in Europe.  And since then I’ve been catching up with various things and trying to get prepared for a couple of speaking gigs.

First up is a session on What’s new in Windows Server 2008 R2 Active Directory for the Wellington Infrastructure User Group.  It starts at 5pm on Tuesday 8th September 2009.  Microsoft are hosting and they usually provide beer and pizza, so it’s worth coming along for that, if nothing else.

The second is a break-out session at Microsof Teched in Auckland on Wednesday 16th:

SVR203 Best practices for upgrading Active Directory to Windows Server 2008 R2

Presenter: Tony Murray

 

Wed 9/16 | 12:10-13:25 | New Zealand Room 1

If you’re going to Teched come along and say hello, even if you can’t make the session (it is, after all, the day after TechFest).

 

Here’s a quick tip on how to find out what ports your AD LDS instances are listening on. 

On the machine running the instance(s), open a command prompt with Administrator privileges and type the following:

dsdbutil “li i” q

The syntax used above runs the dsdbutil.exe utility with the “List Instances” option.  The output should show details of your AD LDS instances, including the LDAP and LDAPS port numbers as shown in the example below.

C:\>dsdbutil “li i” q
dsdbutil: li i

Instance Name:         FE-App1
Long Name:             FE-App1
LDAP Port:             50000
SSL Port:              50001
Install folder:        C:\Windows\
Database file:         C:\Program Files\Microsoft ADAM\FE-App1\data\adamntds.dit

Log folder:            C:\Program Files\Microsoft ADAM\FE-App1\data
Service state:         Running

Instance Name:         FE-App2
Long Name:             FE-App2
LDAP Port:             50002
SSL Port:              50003
Install folder:        C:\Windows\
Database file:         C:\Program Files\Microsoft ADAM\FE-App2\data\adamntds.dit

Log folder:            C:\Program Files\Microsoft ADAM\FE-App2\data
Service state:         Running

Instance Name:         FE-App3
Long Name:             FE-App3
LDAP Port:             50004
SSL Port:              50005
Install folder:        C:\Windows\
Database file:         C:\Program Files\Microsoft ADAM\FE-App3\data\adamntds.dit

Log folder:            C:\Program Files\Microsoft ADAM\FE-App3\data
Service state:         Running

dsdbutil: q

Given that wanting to know the port numbers used by AD LDS is a fairly common requirement, I think it would be helpful if Microsoft made this information available through the Roles view in the Server Manager console.  This would be the logical place for it as Server Manager already shows related information such as Services and Events.

servermanager

Let me know if you agree and I’ll submit a request to Microsoft to make a change.

The other day I had a need to run a demo for a customer that involved showing backup and recovery of AD LDS using Windows Server Backup.  I decided to re-use an existing virtual machine and wanted to start afresh by clearing all existing backups.  Simple enough, I thought, and proceeded to re-format the dedicated backup disk (using diskmgmt.msc).

disks.JPG

When the format was finished I went into the Windows Server Backup UI (wbadmin.msc) and expected to see the jobs cleared.  Instead they appeared as they did before I re-formatted the backup disk.

catalog.JPG

I figured from this that the backup catalog information must be stored elsewhere.  I couldn’t find an option to clear the catalog information from within the UI, so I had a look at the command line (wbadmin.exe) help.  No luck there either.  Eventually, I found an additional Wbadmin delete catalog command in Windows Help and Support.  This had the desired effect of removing the list of backups from the UI (see below). 

messages.JPG 

The only problem now was that the Windows Server Backup UI still displayed messages relating to the previous backup (see screenshot above).  The source of these messages is the Backup event log, as shown in the screenshot below.  If you clear the event log the messages are removed from the Windows Server Backup UI. 

events.JPG

I was hoping for a one-click clear out but, as you can see, it takes a little more effort than that.