Zoho Banner September 2011

Archive for August, 2008

When running through final preparations for a presentation to a few hundred people (well, tens of people…ok, at least 5 people…proabably) the last thing you need is for your Hyper-v environment to start misbehaving.   This is exactly what happened to me and I’ve just found the cause, so am feeling a lot more relaxed about things.

 I had prepared a number of Hyper-v VMs (child partitions, if using the Microsoft jargon) and found I was not able to log on to any of them following a log off.  The VMs were a mix of Windows Server 20008 64bit and 32bit.   When trying to re-log on, I received the error “Your system is running low on resources.  You cannot log on as a new user.  Please use an account that has already been logged on.”

The only workaround I found for this scenario was to shut down the machine and boot up again. 

After investigation the error about “running low on resources” appeared to be spurious.  The VMs were running fine and weren’t under any real resource load.  Assigning more memory and/or additional processors made no difference.  The problem was 100% reproducible.

 In the end I noticed that a newly created Windows Server 2008 VM did not exhibit the same problem.  From there it was a question of trial and error, running through each step of my build process to see what introduced the problem.  Bizarrely, it turned to be changing the default 96 DPI font size to large font (120 DPI).  I had been changing to the bigger font to save my failing eyesight! 

 As soon as I changed the font back to 96 DPI on my VMs the problem disappeared.

 I’m now trying to find out whether this is a bug, or just something weird in my environment.

A number of companies that I work with use the Acctinfo.dll to provide  additional user information when working with Active Directory Users and Computers (DSA.MSC).  You can download Acctinfo.dll from the Microsoft web site as part of the Account Lockout and Management Tools package.

What isn’t quite so well known is that an updated version of the tool, Acctinfo2.dll, has been available for some time.  There is sadly no download available for it and the only way I know to get hold of it is via Microsoft Product Support Services (PSS).  The newer version contains a number of enhancements, such as:

  • Ability to view replication metadata.  This provides the same information as the repadmin /showmeta <objectDN> command.
  • Support for lastLogonTimestamp attribute.  The original acctinfo.dll only shows the last logon for a specific Domain Controller.
  • The tab now appears as an option when users are returned as a result of a search.  This was not the case with acctinfo.dll.

The screenshot below shows the acctinfo2.dll in action.

acctinfo2_11

I was pleased to see from Kurt Roggen’s Blog that Acctinfo.dll still works with Vista SP1 and RSAT.  Based on this, I thought I would try to get Acctinfo2.dll working on Vista SP1 and RSAT.  Unfortunately, I currently only have a 64-bit version of Vista in my VMWare lab environment and it doesn’t work on this platform.  The dll fails to register with the following error:

“The module “c:\windows\acctinfo2.dll” was loaded but the call to DllRegisterServer failed with error code 0×80070002.”

Acctinfo2.dll_4

I’ve since had it confirmed from an authoritative source within Microsoft that the tool won’t load on a x64 platform.  It seems no further development of the tool is planned, which is a shame given that so may people appear to be using it. ++++ Update: news about a 64-bit version available here ++++

There are a number of different versions of Acctinfo2.dll floating around.  If you are planning to request a copy from PSS make sure it is the following (or more recent):

Version 2.0.0.2000 (Modified: Thursday, 26 October 2006)

 

Here’s a cautionary tale.  In a rash moment I volunteered to present a session at TechEd in Auckland in early September.  Be careful what you wish for….I’ve been confirmed as a speaker for a break-out session on Windows Server 2008 Active Directory.  The title is Windows Server 2008 Active Directory Deep Dive and you can catch it on Wednesday 3rd September at 12.10pm.  Or you could simply take an early lunch :-)

I remember the last time I spoke at TechEd.  I woke up at 5am on the morning of my session and thought about gnawing my leg off in an attempt to avoid having to stand up and talk in front of a few hundred people.  In the end it was all ok and I managed to make it through the presentation without looking like a complete idiot (or so my friends tell me…).

I won’t be presenting a session at TechEd Australia in Sydney.  Instead I will be speaking at what they call a MVP Theatre Session.  I’m kind of hoping the Theatre part refers to the venue, rather than a call upon my limited thespian skills.  Anyway, my theatre session is on Administrator Role Separation in Windows Server 2008 at 1pm on Friday 5th September.  Be there or be…at lunch.

If you’re reading this and will be attending either of the TechEd events, come along an say hi (even if you decide to prioritise lunch ahead of listening to my session).

 

Call me rash and impulsive, but the other day I blew away XP and installed Windows Server 2008 x64 Standard Edition on my Dell Latitude D830 laptop.  Other than idle curiosity, the main driver behind my foolishness was the need to create some demo machines using Hyper-V.  I don’t have any other hardware that meets the system specifications for Hyper-V, so it was the laptop or nothing.

The installation itself was a breeze and completed without mishap.  Windows Server 2008 didn’t have the correct video drivers, but I found these fairly quickly on the Dell support site.  They were Vista 64bit drivers, but work just as well for Windows Server 2008.

The first problem I encountered was that the built-in Intel PRO\Wireless 3945ABG wireless connection no longer works.  I found some 64bit Vista drivers from the Intel web site, which seemed to load ok, but I can’t see any wireless networks despite Device Manager showing the device as working properly. The Intel PROSet/Wireless diagnostic tool passes on the driver test, but fails on the hardware test.  The Dell web site also has 64bit Vista drivers but these are older than those from Intel.  I tried these older drivers too, but again without success.

I even tried installing my old Cisco Aironet 350 series wireless card, but couldn’t find any drivers that would work for that either.  The Cisco support site’s latest drivers for the card are for XP.

The second annoyance is that VMWare Workstation guests were working fine until I installed Hyper-V.  Then all hell broke loose.  The VMWare guests started causing the host to bluescreen.  There were also warning messages on the guests about changes to processor speed.  Oh, and I lost 64bit guest support.   Apparently, all this is due to incompatibilities between the hypervisors used by VMWare and Hyper-V.  Happily, I found a workaround on Geert Baeke’s web site that shows how to create a new entry in the boot loader that allows you to select a hypervisorless (is that a word?) boot option.  Good stuff.  Here’s a link to the information.

http://blog.baeke.info/blog/_archives/2007/12/18/3416738.html

Now I’m busy creating virtual machines in Hyper-V.  I haven’t used it before, but it all seems fairly intuitive, especially for anyone already familiar with VMWare.

 

Earlier this week, John Christie posted a question to the mailing list at ActiveDir.org on the topic of the history of Active Directory.  If you’re not already subscribed to the list, the full thread can be found here:

http://www.activedir.org/ListArchives/tabid/55/forumid/1/postid/29103/view/topic/Default.aspx

The most interesting and authoritative response was from Don Hacherl, as shown in full below.

Thanks for tipping me off to this thread, Eric.  I’ll see if I can clear up the pre-history.

The oldest traceable part of AD started life at 3Com in 1988 or 1989.  This was an (incomplete!) X.500-ish directory with custom communication protocols, built on top of a C-Tree database, running under 16-bit OS/2.  By 1990 3Com had abandoned its network software efforts and the directory code moved to Microsoft as part of some complicated deal.  The LanMan group planned to include the directory service in LanMan 3.0 and immediately started porting it to the JET Blue ISAM and building an RPC front end compliant with the X/Open XDS API.

At this point (in early 1991) Jim Allchin, who had recently taken over the LanMan group, cancelled LanMan 3.0 and scrapped its directory service project.  In its place he created the Cairo project, which included a completely non-X.500 like directory service that lived as part of OFS, the Cairo file system.

The email group at Microsoft picked up two pieces out of the wreckage of LanMan 3.0: the DS and an X.400 MTA.  We (this is when I became dev lead of the DS) ported the DS to Windows NT, finished the JET and XDS work, and added a MAPI RPC interface, a query engine, the KCC, a modifiable schema, the link table, and much, much more.  This version of the DSA (plus the MTA and a custom message store) shipped in Exchange 4.0 in 1996.  By this point there’s very little of the original code left, although some elderly data structures live on, at least in name.

Around late 1995 Cairo, and its attendant directory service, were cancelled.  This left the OS team with an urgent need for a DS (for Windows 2000) but no plans to build one.  To fill the hole, the week after Exchange 4.0 shipped two of us from the Exchange DS dev team made a copy of the DS sources and moved to the Windows group, where we got re-christened Active Directory, and the rest is history.

In summary:

  • AD has no relation to Novell NDS/eDirectory.  Novell was a competitor (the competitor), not a licensee/licensor.
  • AD has no relation to Banyan StreetTalk.  Although both Jim Allchin and one member of the AD dev team were former Banyan employees, there was no license or co-work between Microsoft and Banyan.
  • AD has no relation to Cairo, except the relation that mammals have to dinosaurs.
  • AD did not inherit code or functionality from Site Server or MCIS.  It did inherit their customers.
  • AD is a direct descendant of the DSA in Exchange 4.0  (Note that LDAP support got added separately to the two branches of the directory in Exchange 5.something and Windows 2000.  Anything that important is clearly worth doing twice.)

Don