Attach Windows 8 to a Domain

My personal test lab has a fully functional Windows Domain in order to properly test my applications for corporate networks.  As a result, I require all of my windows boxes, when possible, to be attached to my domain for further testing purposes.  Since I’ve just added a few Windows 8 boxes, I had to “learn” the attachment process all over again.

image

image

image

image

image

image

image

image

image

image

image

image

image

After the system reboots, I’m presented with the customized disclaimer message I configured for my domain users… which was the expected results.

image

image_thumb[16]

Now that my system is attached to the domain, I’ll want to log in with my Domain account…

image

image

image

image

Then I’m presented with the new default windows 8 screen…

image

But let’s say I want my domain account to be linked to my Windows Live account.

image

image

image

Warning… the tab button does not work on this user/pass screen… grrrr!

image

image

image

image

 

Please leave your comments and questions below!

Migrating BigFix v8.1 Root Server

In a previous article I described how to install the pre-requisites for BigFix v8.1.  In this article I’ll demonstrate the process for installing the root server and attaching it to a previously existing database.  I’ll be following the How to guide created by BigFix corp (KB133) to migrate my old BigFix physical computer to a freshly installed BigFix virtual computer.

I encountered some major problems with this process… so follow along but remember this is not a perfect migration.

image

image

image

image

image

image

 

I will be using this virtual as a root server only.  My web-reports service will be setup virtual to keep the installations and the processes of upgrading as simple as possible.  So… I unchecked the Web Reports option during the features selection part.

image

image

image

My SQL server is a separate system, so I had to specify the “Remote Database” option and on the next window give the details of connecting to the DB.

image

While specifying the SQL server, it needed to utilize the Computer Browser service.  This service was stopped and/or disabled on my virtual by default.

image

The service was disabled, so I will need to manually enable it so the installer can start it up for use.

image

image

image

image

image

Now, back to the installation…

hitting ok to the error, I hit Next again and answered Yes and all went well… we’re back on track…

image

image

image

image

image

image

image

image

image

image

image

I am utilizing a database that was moved from a previous instance of this license.  Thus many of my logins were already added to the database.  So there is no need to modify this…

image

image

Looks like during the startup process I ran into a little problem.  My FillDB service would not start.

image

Just finish up the install and cancel out of the diagnostics part, we’ll come back to it later.  (since filldb failed to start, expect to see lots of errors)

image


A quick look back at the Services MSC showed the Root Server also failed to start, however the Gather Service and GatherDB started just fine.  This points me to the either database connectivity or a permissions as the cause of their startup failures. 

First I’ll launch the 32bit version of ODBC to confirm connectivity with the database.  C:\Windows\SysWow64\odbcad32.exe

image  image

I don’t need to change anything, just want to test connectivity.  This function is on the last form and the “Finish” button is a shortcut there…

image

image

This shows that my DB connectivity is working through the firewalls that are configured… so I’ll ignore them.

image


Let’s look into permissions.  One of the most important permissions your service account requires is admin permissions to the server you’re running the root server on.  This will allow it access to the Program Files and other special directories.  Let’s start there… and test.

image

image

I don’t see my BigFix service user account listed, so we’ll have to add it.

image

image

image

There it is… now let’s try to start up our failed services… FillDB and Root Server

image


image

image

IT WORKED!!!  Excellent, next I started the Root Server which also worked.  Let’s turn our attention to validation of our installation.

image

image

image

So far so good… let’s take a quick look at our log files to confirm everything is functioning properly…

Two files I’ll be interested in is the BESRelay.log and the FillDBData\FillDB.log  these reside under the Root Servers path… “C:\Program Files (x86)\BigFix Enterprise\BES Server”.

Due to this being a pre-existing database these errors were expected…

image

I’ll first stop all of the services so I can complete step 9 on the How to guide (KB133).

image

Step 9 says to copy the following folders from the old server to the new server:

BigFix Enterprise\BES Server\wwwrootbes
BigFix Enterprise\BES Server\ClientRegisterData
BigFix Enterprise\BES Server\Mirror Server\Inbox

Using a little Robocopy magic… I’m done with this step in.. 2 hours!

Started the services back up and no go… grrrr what was up?

After a lot more research I came across KB215 which discussed the details of “Using NT Authentication with Domain Users or User Groups”.  On step 2 was my answer… my domain service account did not have SA authority in the database.

image

Added the required permission and restarted my services… and I’m done!

Let’s do a little bit more validation…


Validation Part 1

Back to the logs mentioned above… no errors… this is a good sign!


Validation Part 2

Visit http://localhost:52311/rd  for some simple server diagnostics like filldb status, actionsite status as well as downloads status…

image


Validation Part 3

Launch the BES Console, ensure you can connect into the DB and see computers checking in properly…

image


What I’ve learned from this process is pretty simple… you only need a few items in order to completely re-create your infrastructure if something bad happens.

1. (3) folders…
    a. BigFix Enterprise\BES Server\wwwrootbes
    b. BigFix Enterprise\BES Server\ClientRegisterData
    c. BigFix Enterprise\BES Server\Mirror Server\Inbox

2. Database

3. Masthead & auth keys (license.pvk and user keys)

4. Installer which is available at the BigFix website.

 

If you have any questions or comments, please leave them below!

Robocopy’ing Basics

So, you have a large batch of files and want to move or copy them reliably from one location to another.  (this works for nearly all scenarios:  local->local, local->network, ext hd->local, ext ht->network)

Microsoft TechNet reference for Robocopy

Helpful TechNet Magazine article on Robocopy   and another

Download it here if you don’t already have it

All you have to know is this simple command:

robocopy [destination] –z –e

/Z :: copy files in restartable mode.  This means if the command stops because the network is no longer available or some other reason… all you have to do is re-run the command and it’ll pickup where it left off.

/E :: copy subdirectories, including Empty ones.  This will recreate the exact directory tree… so if you’re copying an entire tree (files and sub-directories) it will exactly recreate it even if there are no files inside of a folder.

image

This command also takes advantage of a few defaults:

/COPY: DAT :: what to COPY for files.   This means the files that are copied, will also transfer over the data, attributes, as well as the timestamps like last modified, etc…

/R:n :: number of Retries on failed copies: default 1 million.  This means if the command fails it will sit and retry up to a million times before failing.  I rely on this since I usually run my command overnight.  If the network goes down, it is probably do to a simple power issue.  The hub will go down but the computers won’t due to my UPS’s.  When power is restored and the hubs come backup, the copy will continue.

/W:n :: Wait time between retries: default is 30 seconds.   If it fails as described previously, this is the timer which runs before retrying.  Every 30 seconds upon a failure. 

 

Robocopy is an essential command that everyone who uses computers should be aware of.  Put this one in your pocket and pull it out when needed. 

Installing Tivoli Endpoint Manager (BigFix) Client 8.1.617

Continuing with my installation step-by-step series, I’ll be installing the BigFix client version 8.1.617.0.  This relates to my BigFix Personal Lab infrastructure. 
Get your own trial version of BigFix at the Corp website.

First locate your installer of the client and the corresponding masthead file.  In this step-by-step we’ll be using the EXE and not the MSI version of the installer.

I’ll be installing it onto my root server, a Windows 2008r2 server, however the installation process is the same for the EXE regardless of which Windows OS you’re using except for maybe the UAC dialogs.

image

image

image

image

I’ll be installing with the defaults, since I’m happy for the client to be installed onto the C drive for my endpoints.  However you may want to change the installation directory depending on company policies.

image

image

image

image

That’s all there is to it.  There are a few validation steps I’ll go over here which will give me the peace of mind that it is functioning properly.

Browse to the clients Logs directory, in my case its “c:\Program Files (x86)\BigFix Enterprise\BES Client\__BESData\__Global\Logs” and look for the todays dated log. 

image

You’ll be looking for two very important parts of this log.  The “Attempting to register” which should appear indicating the client itself is working and trying to get to the root server (or relay you specified).  And the “Registered with url” which shows us that it was able to talk to the root server (or relay) and has started the gathering process.

image

 

Please leave your comments and questions below!