Installing Windows Server 2008 EE with Ruby on Rails and LDAP (Part Six)

We've made a lot of progress by now and it's time to start diving into some authentication processes.  The first thing we'll need to do is alter our gemfile.  Place the following into the gemfile of your application:

gem "devise", "1.1.2"

gem "devise_ldap_authenticatable", :git => "git://github.com/cschiewek/devise_ldap_authenticatable.git"

Save your gem file and run a bundle install command.

Now that our bundle is complete, we can run some of the install generators.

=> rails generate devise:install

You'll see that it installed devise.rb into initializers and also added a localization file.  Let's generate our devise user model.

=> rails generate devise User

This generator created our user.rb model, some test files, a migration file, and altered our routes.rb.  Now let's perform a generation for our devise_ldap_authenticatable gem.

=> rails generate devise_ldap_authenticatable:install

This generator created an ldap YAML file, altered the devise.rb file in initializers, modified our user.rb model, and also modified our application_controller.rb controller.

Let's take a look at our initializer, our routes, our user model, and our application controller.

Inside of devise.rb you'll find the following code snippet:

Make sure to uncomment config.ldap_create_user and set to true, config.ldap_config, and config.ldap_use_admin_to_bind and set to true.  This will allow new user information to be saved to our user model when a user properly authenticates from AD.  In addition, we're binding an admin user which will allow us to set the proper credentials for the admin account that will be used to connect through LDAP.  This will be done in our YAML file in a moment.

If you scroll down a little further in this initializer file, you'll find this next snippet of code:

This bit of code helps us configure our ORM (Object Relationship Manager) to work with Active Record.  It's already set by default.  Great.  Let's move on to our User model.

As you can see from our user model below, the new gem has altered the file and placed ldap_authenticatable as a default devise module.

Our application_controller.rb also has some interesting code inside:

The ldap generator we ran earlier added a rescue to our Authenticatable class so that exceptions are rendered via text and provide us a status code of 500.  So, if we encounter any exception errors with LDAP, we'll receive a text message along with a numerical status that will let us know we encountered some type of failure.

Our routes.rb file just contains a very simple route called devise_for :users.  This will redirect all routes to the gem specific paths unless overridden.  This is fine for now.

And, last but not least, we have our YAML file - config/ldap.yml.

We're only concerned with the Environments here.  So, scroll down to development: and have a look at it.  Notice that we have all of the connection entries here to connect to active directory.  However, these will need to be changed.  The best question you may want to ask yourself is how can you find all of the information for Active Directory containers and organizational units?  This is quite easy with a simple application called "LDP.exe".  Go to you run box on the windows server and search for LDP and run it.

1. Click connection --> connect.
2. Type in the name of your server:  corp.ruby.com
3. Leave the port the same and click OK.

You'll find that you are connected to the server.

Once connected, you'll need to bind your connection and use an administrative test account to connect.  In my example, I created two AD test users from part 5.  The admin user was called fred in active directory, but the user account was flintstonef.  So, I'm going to use this account to test the bind with.

1. Click connection --> bind.
2. In the user field type "flintstonef". (this is the admin user I created in part 5)
3. In the password type "Bedrock0". (this is the password I set for this user)
4. In the domain type "corp.ruby.com" (this is the domain I'm using for AD)
5. Once done click OK.

It should look like this.

And once connected you will see this:

And, we're connected to Active Directory.  This is a promising start.  Let's look over our Active Directory tree and determine our base container and user container paths.

1. Start by clicking View --> Tree.
2. Click the dropdown and select "DC=corp,DC=ruby,DC=com".
3. Click OK.

Once the tree is open, we can then browse down to Users and find our path to our admin user.  Look at the picture below:

And this shows us exactly what information we'll need to fill in our development section for ldap.yml in our application.  After placing this in, here's what my ldap.yml file looks like now:

Notice that I changed our base to point to the Users container.  I also changed the admin_user information to point to our admin user.  I commented out everything else.  LDP.exe is very helpful and should prove useful later on as we can use it to browse Active Directory and find out pertinent information we may need for our application.  Make sure to remember this when working with your app.  At this point, we should be able to run a quick test to see if it all works.

First, let's create a generic scaffold to test things with.  How about a post model.  That seems simple enough.

=> rails g scaffold post title:string body:text

Then, we'll run a migration to migrate everything up to the current schema.

=> rake db:migrate

And, we can see that our devise users table and our posts table successfully migrated.  So far, so good.

Let's run our stop/start .bat file (the new service) we created in part 5 as an elevated "administrator" by right-clicking it to start the server.  And, after doing so, I'm going to open up a page and go check out the posts route.

And, our server is responding and I'm able to create a post.  Great.  But, there's no authentication being performed on this view.  Let's correct that.  We're going to edit our application_controller.rb file and add a before_filter for authentication through devise.  It should now look like this:

We added before_filter :authenticated_user! to our class above.  Let's save it and refresh our app.

Now, when I tried to login, the first thing I noticed is it's asking me for an email address.  This poses two problems that I can see right now.  First, I didn't specify an email address for my user account in AD.  Let me do that for fred now:

Also, because we're looking for an email address instead of a username, we need to correct one part of our ldap.yml configuration file and change the following:

attribute: cn

TO

attribute: mail

This will allow our authentication system to search for the correct attribute and this should fix this issue.  If we go back to my application and type in:

fred@corp.ruby.com with password Bedrock0

Successful authentication!  Let's check the logs:

If you click on the image above, you'll see that it found the user in AD, and also found that the user didn't exist in our User table.  It successfully added our user to the table and authenticated us.  I was able to post.

If you made it this far without any hiccups, pat yourself on the back!  We are now using Active Directory to authenticate and login to our application.  We did this with Thin and Apache and did not use fastcgi or IIS.  In our next part, we'll do some cleanup, add some user based checking, and also add some test unit code to ensure everything is working fine.

See you in part 7!

Installing Windows Server 2008 EE with Ruby on Rails and LDAP (Part Five)

At some point in our application we'll be automating a few things like our server start.  As we're running an apache load balancer and a fast HTTP server in Thin, it might be easier if we can create a service for our Thin server since Apache already has one for itself.  With Windows Server 2008, unfortunately there's no resource kit currently published by Microsoft.  In addition, if you try to run the SC command to create a service, it will point to a missing srvany.exe file.  We can get around this by downloading and installing the windows server 2003 resource kit locally, and copying the srvany.exe file into our C:\Windows\System32 directory.  Let's do that now.

First, grab a copy of the windows server 2003 resource kit here:

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en

If the download link becomes outdated, just google or bing a search for Windows Server 2003 Resource Kit and you'll find the right one.  Once you download and install it (I'll install mine into C:\Tools, go ahead and copy the srvany.exe file into your system32 directory.  Now that we have that part done, let's move right along.

First, the nice thing about working with Windows is that you can create some automated services.  If something goes wrong, or a server needs to be restarted, the service can do it automatically.  This makes things easier.  In terms of what we'll be doing, we're going to create a development service just to test the functionality for later on.

Before launching a command prompt, right-click on the command prompt and run as an administrator.  This ensures we have elevated permissions when performing our command.  The command for creating a service will use the following protocol format:

sc <server> create [service name] [binPath= ] <option1> <option2>...

So, we'll use the following command:

sc create RubyThinServer binPath= "c:\windows\system32\srvany.exe" DisplayName= "Ruby Thin Server"

Also, note that there must be a space between the "=" sign and the value.  In the case for the statement above, the space comes after binPath= and also after DisplayName= .  There's no need in supplying the server name here.  Once you apply the command you should have a success message.

Now we need to edit the registry settings for our service and add our parameters.  Use regedit and go to the following key:

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RubyThinServer\Parameters]
"Application"="C:\\Ruby192\\bin\\ruby.exe"
"AppDirectory"="C:\\Web\\ldap"
"AppParameters"="C:\\Ruby192\\bin\\thin start -p 3000 -e development"

The above snip can be copied and pasted into a .reg key and added automatically to your registry if you are using the exact same settings I am.  If you aren't, then you'll need to do the following:

Create a Parameters key for your RubyThinServer registry setting.  In the Parameters key, create strings for Application, AppDirectory, and AppParameters as specified above.

Once this has been completed, we can now start our service by going to services.msc and right-clicking our new service and choosing start. 

Once the service has been started, open a browser and navigate to http://localhost or http://ror-devapp01 (the name of my server) and the page should open as thin has been automatically started. 

It has..  Nice! 

You can change the parameters later on to make the service automatic and only allow it to work with production mode by putting in: 

"AppParameters"="C:\\Ruby192\\bin\\thin start -p 3000 -e production"

As you can see from this example, we're now going to make things easier for us by simply starting our service.  But, what if I don't want to run this manually, or I would rather be able to stop or restart the service via a quick executable?  Well, we could just use DOS for this and create a .bat (batch) file:

@echo Stopping the Ruby Thin Development Server
sc stop RubyThinServer
pause
@echo Starting the Ruby Thin Development Server
sc start RubyThinServer
pause
exit

You would then store the batch file on the desktop and right-click and run it as an administrator so you have elevated permissions.  It will stop the server, and when you press any key, it will start the server.  If you changed the service to start automatically with retries in place, you could just perform a stop command and the service would automatically restart on its own.  You could also go into PowerShell and create a nifty service cycle, or even go one step further and write a system tray GUI in Ruby and make your service start up whatever way you'd like to do so using the Win32 library.  I'll leave this customization up to you.

One more thing before we move on.  It might be prudent to set a dependency in the service to ensure that the apache service is started and running.  Since we're depending on Apache first, it should be running before Thin starts.  Again, I'll leave this customization up to you.

Active Directory

Well it looks like we'll finally get to Active Directory today.  One thing I'd recommend for any of you is to try to closely mirror how AD looks on your company site so that you can make sure everything aligns properly when working with LDAP authentication.  We're not going to do a lot in AD, except create an administrative user and a regular user for testing.

If you are unfamiliar with AD, then I'm not sure why you are reading this article. :)  So, I'm going to assume that you have a basic understanding of how to create users and groups in Active Directory.  Go ahead and create two users.  For your administrative user, make sure he/she has full rights to all administrator groups (domain admin.. etc.).

In my example, my admin user will be Fred (flintstonef), and my normal user will be Barney (rubblem).  Barney will be a normal domain user.  If you like the flintstones then you'll like these two users. 

Once you have these two users created and assigned to the correct groups, we're ready to get into adding our ldap gem and creating a test for our ldap connection.  See you in Part Six.

Installing Windows Server 2008 EE with Ruby on Rails and LDAP (Part Four)

So, we've made a lot of headway through the last three parts.  But, we haven't really checked to ensure that Apache (our load balancer) is working.  In addition, we need to configure it to accept proxying to THIN so that our fast HTTP server is working together with it.  Let's do that now.

If you notice on our server, apache is already running as a default service.  All we need to do is check and see if it's running by opening a browser and pointing the URL to http://localhost/ .  Notice that we're not pointing anything to a specific port, nor are we running our rails application here. 

As you can see here, it says that "It works!".  So, apache is working fine.  Let's look at how we are going to configure it to work with Thin.

If you drive down into the following directory:

C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf

In this directory, you'll find httpd.conf which in windows looks like a text file.  If you open this, you'll find all of the apache configurations for your local server.  Before you dive into this, there are a few ways we could go about setting this up.  If your server is going to be using apache and has a lot of virtualization, you could include this file and make your changes specific to this vm in httpd-vhost.conf, or similar.  But, since we're trying to make this as simple as possible, we'll make our changes in here.

We need to first uncomment the following two lines:

LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so

We'll be using these two modules to proxy requests coming into apache and force them to go to Thin.  In addition, we'll need to add some information to our virtualhost.  Here's the additional information we'll be adding to httpd.conf at the very bottom of the file:

<VirtualHost localhost:80>
      ServerName ror-devapp01
      DocumentRoot "C:/web/ldap/public"
      ProxyPass / http://localhost:3000/
      ProxyPassReverse / http://localhost:3000/
      ProxyPreserveHost On
</VirtualHost>

<VirtualHost ror-devapp01>
      ServerName ror-devapp01
      DocumentRoot "C:/web/ldap/public"
      ProxyPass / http://localhost:3000/
      ProxyPassReverse / http://localhost:3000/
      ProxyPreserveHost On
</VirtualHost>

So, let's look over the information above and determine why it's being set this way.  The ServerName is normally the live address of the server.  The documentroot is the location of the rails public directory in our rails application.  If you open a web browser and go to http://localhost or http://ror-devapp01 (the latter remember, is the name of my server), you'll see it is just pointing to "It works!".  What this says is that apache doesn't know how to handle incoming requests and send them over to Thin.  By adding the virtualhost for localhost, we are saying to pass this proxy over to localhost:3000 which happens to be the address and port of our Thin server.  In addition, we also have to add a virtual entry for our server name because otherwise the http://ror-devapp01 would also fail to pass over to Thin.  By adding both of these entries we accomplish this.

However, we still need to two more things after saving this modified httpd.conf file.  We need to start our Thin server by going into our root rails application and typing "rails s thin", and we also need to restart the apache server, which can be accomplished either by restarting it from the apache tool in your system tray, or going to services and restarting the apache service.  We need to restart apache services because we made changes to the httpd.conf file.

Let's open a web browser and test both URLs now:

http://localhost
http://ror-devapp01 (or the name of your current server)

Look at that, they pass right over to the Rails Thin server!

With this new information in place, apache can now handle incoming requests to localhost and to our server directly, passing them over to the Rails Thin server which acts as our fast HTTP server for this application.  Now that we have this part done, we can come back to apache later on for further configurations and modifications.  As a quick review, we have everything setup to start working with our base application.  Apache has been initially configured, Ruby and RoR is up and running, we have a good understanding of how all of the configuration is working together.  The only thing we haven't decided on is what type of application we will be creating.

Before we jump into some programming in our new environment, it is going to be appropriate to decide how we want to work with our application as far as an editor.  I could make this very simplistic and go with a simple text editor, but I like a fully functioning IDE as my preference, and Netbeans works wonderfully on Windows. Why not take advantage of that?

We can find the latest netbeans here:

http://www.oracle.com/technetwork/java/javase/downloads/jdk-netbeans-jsp-142931.html

I'm downloading Netbeans 6.9.1 with JDK 6.24.

Before we go and get it, we'll also need to make sure we install the latest JDK library as well.  The good news is that netbeans comes with a bundled install that houses JDK, and we can just grab the bundled version and begin our installation.

After installing it, and launching it, Netbeans takes you to a generic home page.  The first thing I want to do is set my netbeans up so it looks a little friendlier. 

If you go to Tools --> Plugins and go to the available plugins tab, you can type the word Ruby in the search box and you will find two plugins that are essential for ruby development.  These are Extra Color Themes and Ruby and Rails.

Place a checkmark in both boxes, click install, accept the license agreement, and install the plugins. Once finished, restart Netbeans.

Now that we have our plugins installed, let's perform some configurations for our programming environment.

Go to Tools --> Options, and select Fonts and Colors.  Change the profile to "Aloha" and click OK.  This will make our programming code look very similar to textmate. 

Now that we have our fonts and colors setup, let's configure our Ruby platform and open our default ldap project.

Go to File --> New Project, and select Ruby, and then select Ruby on Rails Application with Existing Sources.  Click Next.

On the next screen, change your project folder to C:\Web\ldap and name your project LDAP.  Click the drop down next to Ruby Platform and choose the Ruby 1.9.2-p180 platform (or your existing ruby platform).  Leave the server set to webrick.

Don't worry about the Server type.  We're not going to use Netbeans to start our server.  We're just going to use it for everything else.  Go ahead and click finish and once completed, you should see your rails LDAP project now.  Just for fun, go ahead and open up the Gemfile and everything should look similar to the screenshot below:

Terrific!  So, I would go ahead and browse around the interface and get familiar with the directory structure of our new application.  We've accomplished quite a bit today and we're ready to start working on some further configurations within rails, and adding some more important gems to our project.

Again, we haven't really started coding yet so you can see how extensive it can be sometimes with just trying to get your project started.  However, as you have a fully functioning environment setup, you won't have to take quite as much time to setup the next app.

See you again in part five.

Installing Windows Server 2008 EE with Ruby on Rails and LDAP (Part Three)

In Part Two, we successfully installed Apache and Ruby.  In this part, we’re going to focus on Rails, some gem dependencies for our application, and decide on our database and web server in rails.  Once done, I’m going to try to work on some additional configuration for our server.  So, with that said, let’s start with installing Rails. 

First, there are two choices we can make here.  We can install the latest version of Rails, or install the latest version of EDGE rails; the latter being the cutting edge of rails development.  Because my goal here is working with LDAP authentication and functionality, I’m going to stick with the very basics.  Let’s start.

=> gem install rails

As you can see, rails installed a lot of core dependencies here.  Now, I want to make things simple in terms of where my app is going to launch.  So, I’ll create a directory called Web in the root of C:\ and place my new application in there.

C:\>md web

C:\Web>rails new ldap

Good.  I now have a new application for rails called ldap located in C:\Web\ldap.

I’m also going to have to install the DevKit properly in case any gems need to be built on Windows Server 2008.  I already have the development kit downloaded, so I’m going to extract it into a directory called:

C:\DevKit>

Once extracted, I need to go to that directory and type the following commands:

=> ruby dk.rb init

=> ruby dk.rb install

The init command creates a .yml (YAML) file that houses the directories on the server where ruby is installed.  By default it knows that Ruby192 was already listed in C:\ and so no modification was necessary.  Once I ran the install, it created some enhancements in the existing ruby directory for C:\Ruby192.

If you need to see more instructions about the DevKit, you can go here:

https://github.com/oneclick/rubyinstaller/wiki/Development-Kit

The Database

Rails already comes with a default database called SQLite3.  Because this is a simple test application, I’m going to keep this default.  However, Windows Server 2008 doesn’t know what this is.  You still need to download the .dll library.  You can find it here:

http://www.sqlite.org/download.html

I only need the .dll so I’ll install that in downloads and then extract and move the .dll into my C:\Ruby192\bin directory.  This directory is already added to my system path, so it’ll find it just fine.

I’ll modify the gem file and take a peek and for now, everything is exactly what I need.  There’s nothing I need to do here until later.  Let’s go ahead and test whether or not we have a basic functioning rails app.

C:\Web\ldap\>bundle install

C:\Web\ldap\>rails s

Bundling will make sure any gems, and dependencies I need are installed and once complete, rails s will start the server.  Once the server starts (using a generic webrick server), let’s go to http://localhost:3000 (in my case) and take a look:

Great!  It’s working.  We’re riding Ruby on Rails on Windows Server 2008.  No time to pat myself on the back yet, I still have quite a few things left to do here.  Let’s get to work!

I want to get thin installed, but unfortunately on Windows, thin (which requires rack and eventmachine) can be a pain in the butt to install.  However, there’s a great work around we can do on Windows to get this installed and it partly uses “Git” to accomplish this task.   I’ll eventually be using Git anyways later on to backup my source code, so I’ll just go grab a copy of it from here:

http://code.google.com/p/msysgit/downloads/list

When I install it, I want to include the git bash here and git gui here context menu entries and also make sure you choose “as is” on the following screen so you don’t get the CRLF issues when pushing your source files later on.

Now then, I have Git successfully installed, but before I do anything I’ll need another gem called specific_install.  From a windows command prompt type the following:

=> gem install specific_install

Now that I have this gem installed, I’ll right-click anywhere on a directory in windows explorer (and choose git bash here).

Run gitbash and type:

=> gem specific_install -l git://github.com/eventmachine/eventmachine.git

This should install the latest beta or latest eventmachine file, which is required by Thin to operate.  Rack already came with the latest version of rails, so nothing is needed here.  You might be saying whoa!! Why aren’t you just using the Developer Kit and compiling eventmachine.  Well, on windows server 2008 64-bit, that’s not going to work.  I will get a compile error with eventmachine only.  Now then, once downloaded  let’s run (from the windows command line):

=> gem install thin

Great, it installs just fine!  Let’s try running it: (using the command rails s thin)

And, let’s open a web browser and see what happens:

.. yay, it’s working. 

So, the one thing that people may complain about with Ruby and Ruby on Rails is that setting things up is no easy task on Windows.  This is primarily why most people that develop with Rails tend to use Linux or Mac, and even Mac can run into its own complexities.   With Windows however, you have to remain calm and be patient throughout the installation process.  Before we continue, let’s recap what we have accomplished so far:

• Installed and configured Windows 2008 Server EE (64 bit) with Active Directory as its primary role (although AD is not currently configured)
• Installed Apache 2.x (as our load balancer) (still needs configuration)
• Installed Ruby 1.9.2(p180)
• Installed the Ruby Development Kit
• Installed Ruby on Rails v. 3.0.5
• Configured Sqlite3 as our database
• Installed THIN as our fast HTTP Web Server
• .. and tested that it works for the most part.

That's a pretty big list already!  So, before we move on, let’s take a break and rest and come back tomorrow and continue with our setup.  See you in part four..

Installing Windows Server 2008 EE with Ruby on Rails and LDAP (Part Two)

So, looking back at part one, I was happy to get most of the server software installed and initially configured.  However, I know there’s still quite a few things to do here.  I haven’t even started to install Ruby or RoR yet, and it's always a lot of fun having to grab a hundred or so critical microsoft patches! 

The next thing that I need to do is perform a few updates, namely running windows update to get the server up to par.  Once done, I’ve decided to disable Internet Explorer protection, which is the largest nag feature ever invented for Windows Server Environments.  Normally, in a production server environment, there’s absolutely no reason to have browsing enabled.  But, since this is a 100% test environment, I want to enable it.  The easiest way to do this is through the administrator tools à server manager. 

If you click on the root of the Security Manager and scroll down to Security Information, you can click Configure IE ESC.  I’m going to turn this feature off for both admins and users.  It will make testing easier.  But, again, on a normal production server you would not have any browsing on anyways so this would not be turned off.

Once our updates are completed and the server has been restarted, we can start thinking about how we want to go about the rest of the project.

Deciding on Web Servers

After much research, my goal is going to be to use Apache as a Web Server load balancer and couple it with a fast HTTP server that can run Ruby.  I can go with either Mongrel or Thin in this respect, but I’ve decided that Thin will work best for this first project.  Mongrel or Thin can work completely on their own without Apache, but they wouldn’t be able to handle load balancing and it would only allow for a very light load.  This is why I’m using both together.   The only thing to note is that Apache does not come with 64-bit support for windows.  Oh well, we can’t have everything perfect now can we?  To simplify things, here is a list of items I will be downloading before I continue:

Downloads:

Apache:

http://httpd.apache.org/download.cgi

Ruby 1.9.2:

http://www.ruby-lang.org/en/downloads/

http://rubyforge.org/frs/download.php/74298/rubyinstaller-1.9.2-p180.exe

Developer Kit-Ruby:

http://rubyinstaller.org/add-ons/devkit/

http://github.com/downloads/oneclick/rubyinstaller/DevKit-tdm-32-4.5.1-20101214-1400-sfx.exe

Once everything has been downloaded, I’m ready to start the installation of Apache.  Everything appears pretty simple here.  I chose all of the defaults, changing the administrator email to a local one, and selected the default locations.  Once the installation is completed, I see the apache icon in the system tray and it shows the service has been started.  So far, so good.  Let’s go ahead and install Ruby.

I’m going to keep the default ruby location for C:\Ruby192, but I will set the ruby executables in the path and associate the .rb and .rbw extensions.  I will then click install and let it finish the installation.

Now that the basic installations are installed, let’s test out Ruby and see if it works.

We can do ruby –v to find out our ruby version.  We can also do a gem –v to find our gem version.  Finally, we can run IRB and type in 2 + 2 to see 4.

The paths were already set so we can do this from any command prompt in any path.  So far so good!  If I run a gem update system there’s nothing to update.  Okay, we’re in good shape here.  At this point I’m going to save my snapshot and make sure everything is saved.  We actually covered a lot in this part two, so we'll work on some new things in part three.

Installing Windows Server 2008 EE with Ruby on Rails and LDAP (Part One)

One of my burning short term ambitions has been to build some key ruby on rails applications for my company.  My company is primarily a windows shop that uses ASP.NET and Windows Server 2008.  Like most companies, sometimes it's difficult to move away from standardization and into innovation.  I'm not saying that Ruby and Ruby on Rails is the most innovative language and framework around.  No, I'm merely stating that sometimes it's difficult for people to move away from standard practices and think outside of the box.

So, to further my own ends, I’ve decided to build a Ruby on Rails application on Windows Server 2008 Enterprise Edition.  It appears difficult, it’s a nice challenge, and I want to showcase some nice RoR apps to the management team at my company.  But, I know I’m going to be stretching things a bit to get everything I want out of a pure windows shop.  The easiest thing I can do here is to focus on a few core ideas that I've been interested in, and go from there.

My company loves using ASP.NET with IIS and Active Directory.  I don’t want to use or have to rely on IIS for anything in my application.  I will definitely need to communicate with Active Directory so I need some type of LDAP communication in my app.  IIS and Fastcgi is too cumbersome imho, and I already have a few concepts in production on linux that I want to try and use on windows.  So, instead I’ll be using devise_ldap_authenticatable (https://github.com/cschiewek/devise_ldap_authenticatable).  This gem will allow me LDAP functionality with Active Directory and I can skip using IIS and fastcgi, which sometimes becomes an alternative in this scenario.  I might make some folks angry in my work place for bypassing IIS, but that's to be expected.  You can't make everyone happy.

As far as web servers are concerned, I want to use Apache as my load balancer.  It can handle the amount of people that will access the applicatioin, and it will allow me to use a faster web server with my rails application.  I had originally thought about using Mongrel, but I've started to move away from Mongrel lately.  I'm opting for Thin instead. 

But, for now, let’s start with some initial setup and work on customization later. 

I will need to use Windows Server 2008 EE, and one nice item that Microsoft provides is a free evaluation copy of this OS for 60 days that can be re-armed 3 additional times.  Re-arming allows you to reset the 60-day evaluation by running a supported Microsoft script.  That gives me 240 days of free evaluation of Windows Server 2008 EE, which is more than enough time for me to develop and showcase my app to the management team.  I will also put it on VMWare so that it’s virtualized, which will allow me to make snapshots before implementing critical changes down the road.  So, let's start by grabbing a copy here: 

http://www.microsoft.com/downloads/en/details.aspx?FamilyId=13C7300E-935C-415A-A79C-538E933D5424&displaylang=en . 

Don’t worry if the download link doesn’t work or isn’t correct.  Just do a search for it and you’ll find the free version of the one you want to use most.  In my case, I’m going to use the amd64 version because I am coding on a 64-bit machine.  So, I’ll grab a copy of the ISO for amd64, store it on a secondary development drive, and I’m ready to begin setting it up.

Installation is going to be fairly simple here. I can launch VMware, click New Virtual Machine, and point the new installation to the ISO image I downloaded.  I chose Windows Server 2008 Enterprise and will use the simple install to finish up the installation.  When I was asked for the license key, I left it blank and hit next and chose NO so that the activation would not take place.  This will start the 60-day evaluation timer and I’m off and running.  In terms of what type of VMware hardware I’m going to run, I think I’m going to set the space to 60GB, and use 2GB of RAM for the server.  That should be more than enough to start.

Once it’s fully installed, I see the following startup screen:

The first thing I think I’m going to do is install the VMware tools.  This can be done by clicking VM, clicking reinstall VMWare tools, and running the setup.exe program when the popup arrives.  You can then click next, followed by modify, and I’m going to make sure that all features of the tools are installed.  Once completed, I click next, and modify again, and the toolset is reinstalled with everything requested.  At this time, I think I’m going to restart my server and make sure everything looks fairly clean before I go any further.  (waiting.. waiting.. eating popcorn..)  Hey, it appears to be running fine!

Choosing what roles this server will perform is going to be a little different than I expect to see at my work place.  This is mainly because I need to test Active Directory and so I’m going to make this server have an ADDS role.  With ADDS, you can’t add Application or Web Server roles at the same time. 

Click Next and accept the defaults and choose install to begin the ADDS installation.  Once finished, I will need to run dcpromo.exe to make it a fully functional domain controller.  But, I don’t want to do this just yet.  I think I’m going to change my server name first.

I like ROR-DEVAPP01 as a good name (Ruby on Rails – Development Application 01).  Once I change the name, it’s going to ask me to restart and I can work on the domain controller promotion next.  When it’s restarted, I go to Start, type in dcpromo and hit enter and begin the installation.  I don’t want to use advanced installation features.

The first screen is a little daunting because I got a nasty big scary screen talking about older operating systems and algorithms, etc. – wooo.., ghosts in the machine.  Why does Microsoft always want to scare the hell out of you!

I skip the message, continue right along and check “Create a new domain in a new forest” and click Next.  How about that, another big scary looking message!:

This just states that the Local Administrator account either doesn’t have a password set, or it’s not a strong enough password.  Well, how about I change it to [administrator = !Ruby on Rails#] | [admin = !Ruby on Rails#].  This will fix this error.  You can accomplish this by going through Computer Management.

I’m going to name my FQDN after something fictitious – how about corp.ruby.com.  After performing some verification, everything checks out.  I’m going to set the functional level of the forest to Windows Server 2008 and click next.  In addition, I’m going to leave the DNS server checked, and click next.

At this point the IP address will be dynamically assigned for now, so click Yes.  Normally, I would set this statically, but this is a test environment.  Since we’re working in a virtual environment, it’s pretty simple to keep this setting as dynamic for now.  Production servers would have static IP addresses assigned.

I accept the defaults and ignore any errors, and reboot upon completion.

So, it’s been a pretty good start for part one.  I have a Windows Server 2008 EE server setup with active directory and DNS, the forest has been named, and the sever has been renamed as well.   I’ve built some simple personalization and virtualization is complete.  I think I’ll stop for now and start again tomorrow.  Here’s what it looks like at the end of Part One:

We'll cover more in part two.  See you then!