When working with vRealize Orchestrator and Active Directory it has been possible for a long time to use the built in Active Directory plugin for many tasks. One of the drawbacks with the various iterations of the 1.0.x version of the plugin however, was the lack of support for multiple domains and multiple domain controllers. This was naturally quite restrictive in environments with more than a single domain which is pretty common for many reasons since as distributed management, mergers & takeovers and poor planning ;-)
In this series we will see how to automate the creation of a tenant in vCAC using vCO. There are multiple tasks to provision a tenant in vCAC, so even though it is an automation product itself, there’s no reason why you shouldn’t look at automating parts of it too.
In part 2 we will create the AD Users, Groups and OUs to support the vCAC tenant. In this example we will create:
In this series we will see how to automate the creation of a tenant in vCAC using vCO. There are multiple tasks to provision a tenant in vCAC, so even though it is an automation product itself, there’s no reason why you shouldn’t look at automating parts of it too.
In parts 1 and 2 we will look at the AD requirements for a tenant. Since most organisations will likely use AD for authentication we will create the minimum users and groups required for a vCAC tenant in a structure that lends itself to further expansion.
Need to create a random password in vCO, maybe to be able to create a user account in Active Directory or elsewhere? I created an action for this task which can be reused in any workflow. The code for this is below.
There’s one input passwordLength to determine how long you want the password to be.
The action can be used in a workflow like so:
Alternatively, you can download the action to import into your own vCO install from my vCOModules repository on GitHub, where I’m beginning to store modules of generic actions I use.
During the setup wizard of the vCenter Server Appliance I experienced an error at the step to make it Active Directory Enabled.
In this instance I received the below error:
Failed to execute ‘/usr/sbin/vpxd_servicecfg ‘ad’ ’test’ ‘sunnydale\vcentersvc’ CENSORED ‘sunnydale.local’’: VC_CFG_RESULT=309(Error: Invalid hostname. FQDN is required for joining a domain.)
Initially I thought it may be something to do with how I was specifying the AD domain name or username. Didn’t get very far with that, so I skipped it for the time being and decided to come back to it later.
Wanted to let readers know that I have a 50% off promo code for an upcoming book from Richard Siddaway, ‘Learn Active Directory Management in a Month of Lunches’. It’s now available in Manning’s Early Access Program and I have a 50% of promo code which is valid until Feb 26, 2013 12 midnight EST. Use the code below when ordering:
learnadmau
Here’s the book abstract:
Active Directory is the heart of a Windows network, providing a centralized location for administration, security, and other core management functions.
By default, Data Encryption Standard (DES) encryption for Kerberos authentication is disabled in Windows Server 2008 R2, this is a change from Windows Server 2003. If you are running an application which uses DES encryption for Kerberos application, such as SAP, then you may see issues authenticating users against 2008 R2 DCs. You will see errors in the System Log like the below for the users in question:
“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).
To upgrade Active Directory from Windows Server 2003 to Windows Server 2008 R2 requires the usual AD schema upgrade first of all. Windows Server 2008 R2 is 64-bit only, so if you try running the usual command to upgrade the schema from a 32-bit Domain Controller:
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:
The larger your organisation gets so do the number of users within your Active Directory and consequently the chances of employing people with the same name. Unless you have good naming policies from the start you may well end up with an untidy directory and if you are using Exchange an address book where it is hard to distinguish between people with the same Display Name.
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.
The first two sessions of the UK PowerShell User Group for 2010 will be online sessions.
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.