Field Day delegates descend on Coho Data

I posted my first official post on Coho Data’s blog page. It’s all about the Virtualization Field Day (#VFD3) experience last week.

Jump on over here to read the details: http://www.cohodata.com/blog/2014/03/07/field-day-delegates-descend-on-coho-data/

Remember, there’s less than a week left to vote for the best virtualization blogs. Perhaps you want to add some of the VFD3 delegates to your top 10?

I’ll be at #VFD3 tomorrow with Coho Data

A quick note to let everyone know that I’ll be at Virtualization Tech Field Day (#VFD3)  tomorrow for the Coho Data session . Andy Warfield will lead the charge and I’ll be there delivering a short session.

I’m really looking forward to meeting all the delegates – Steven Foskett and his staff have gathered a great crowd again. I’ve met several of them before, if not person, then in some virtual capacity. It’s always fun reconnecting with folk from our community, and having the opportunity to make new friends as well.

So clear your schedule for tomorrow morning: 8am to 10am (Pacific). Andy treated everyone to fascinating session at the last Storage Field Day, and I think the virtualization community are going to really enjoy a deep-dive into the Coho Data technology during this session. Tune in to the live broadcast here: http://info.cohodata.com/VFD3reg.html

VFD-Logo-150x150

A Linux-based Domain Controller for a vSphere lab – part 4

This is a four-part series of posts explaining how to install and configure a Linux-based appliance in your vSphere lab environment to take the role as a Windows Domain Controller.

Update: Fernando Pimenta has been kind enough to translate this series into Portuguese. You can find the translated copies here.

Creating the accounts

Completing all three previous parts take us to the dashboard which has a great layout. At this stage, if you chose to set this as a standalone domain, you’re done! The domain controller is configured and ready to use.

13 Dashboard

Before we can join any clients to it, we’ll add a regular Domain Admin account (not to be confused with the zentyal admin account created during the install).

  • Under the Users and Computers menu, select Manage. I highlighted the Users OU and clicked the green Plus sign.

14 Users and Computers

The admin account you create during the install and the “Administrator” account seems to be hidden reserved account names.

  • I created a cunningly obfuscated account called domainadmin and added it to the Domain Admins group.

15 Domain admin

  • At this stage it’s probably worth creating another user account for regular vSphere administration. Something like vi-admin.

GPOs

Before I move onto the vCenter configuration, it’s worth pointing out that the dashboard shows the GPOs applied across the domain. But there’s no way in the Zentyal GUI to create or edit them. To do this:

“Even if you don’t have any Windows Servers in your domain, it’s still possible to create and enforce any GPO using a Windows client joined to the domain. Installing Microsoft RSAT tools and logging into the client using the Domain Administrator LDAP account, you will use RSAT interface to design the desired GPO. The GPOs will be automatically added to the domain SYSVOL and enforced by the Zentyal server.”

Configuring vCenter

You can use your newly formed Domain Controller with either a Window-based vCenter, or the Linux-based VCSA. I’m guessing for the same reasons you’re looking not to use a Windows Domain Controller, you’re probably the clever type of chap or chapess that would favour VCSA. Suffice it to say that it should work well in either case.

There are plenty of good guides on the web explaining how to stand-up a VCSA v5.5, but just to prove that I haven’t forgotten my l33t vSphere admin skills, here’s a quick summary:

  • Deploy the VCSA ova
  • Power it on
  • If the subnet has DHCP, then log into https://your.ip.address:5480 page (default username and password is root / vmware)
  • If the subnet doesn’t have DHCP:
    • Login into the VCSA console and run
/opt/vmware/share/vami/vami_config_net

     and follow the menu prompts the set the IP configuration required

  • Once you can log into the admin console:
    • Accept the EULA
    • Accept the default settings
    • Set the hostname setting with an FQDN

It’s now relatively straightforward to join your vCSA to a domain:

  • On the vCenter Server Appliance admin web interface > vCenter Server > Authentication, and fill in the domain, username and password. 

16 Joining VCSA to domain

  • Stop the vCenter service
  • Set the password for the [email protected] SSO user
  • Start the vCenter service

Now you can log into the Web Client as the [email protected] user.

  • Go to Administration > Single Sign-On > Configuration > Identity Sources tab

17 Adding domain in web client

  • Click the green plus sign
  • Select Active Directory (Integrated Windows Authentication) and add in your domain name

18 Adding domain in web client 2

  • Highlight the domain in the list and set it as the default domain (the blue circle with an arrow pointing into it)

19 Domain added

  •  Log out and log back in with your domain admin account

20 Logging into web client

  •  Success!

21 Success

At this stage, if you’ve created a domain account for vSphere administrative work, you should head to the appropriate level in the vCenter hierarchy and give the account the appropriate permissions. For example, if you created a vi-admin account, you could go to the root object and give the account the Administrator role.

We’re done creating and configuring your Domain Controller and successfully joining vCenter to it. For bonus points, you could now start joining your ESXi hosts to AD. Either way, the panda is super happy.

12 Panda

A Linux-based Domain Controller for a vSphere lab – part 3

This is a four-part series of posts explaining how to install and configure a Linux-based appliance in your vSphere lab environment to take the role as a Windows Domain Controller.

Update: Fernando Pimenta has been kind enough to translate this series into Portuguese. You can find the translated copies here.

Selecting the roles

Following on from part 3, log into the administrative web page with the username and password you provided whilst deploying the appliance.  You’re presented with 4 standard Server Roles, each of which selects a subset of appropriate Modules, or you can individually select Modules.

6 Zentyal package selection

I could have chosen the Infrastructure Role as the basis for this Domain Controller and tweaked it, but instead I individually selected the following Modules. The “File Sharing and Domain Services” Module is all you need to select for a Domain Controller and the other Modules are pulled in as dependencies, but I thought the other packages I picked would be useful in my lab.

  • Click Install at the bottom right of the grid.

7 Zentyal packages selected

  • Confirm to go ahead with the module installs (a number of other dependency packages are picked up).

8 Zentyal package confirmation

Configuring the appliance

Once the packages are installed the configuration stage begins. First, you set which network interfaces are trusted. In my case I didn’t create a multi-homed VM so there was only once interface to set. This is my lab so I threw caution to wind and set it to Internal.

9 Network interfaces

  • Set a static IP address

10 IP settings blanked

  •  I’m not joining this to an existing domain, so kept this a Standalone server and set the domain name.

11 Standalone domainMore module changes are made which can take a few minutes.  Once the changes are complete a friendly Panda invites you to click onwards to the Dashboard.

12 Panda

Part 4 concludes this series and explains how to configure vCenter to connect to your Zentyal appliance.