Posts

How to install MongoDB on Windows Server 2012 with a replication set.

This post is currently outdated, please have a look here to see a up to date version:
https://community.ulyaoth.net/threads/how-to-install-mongodb-on-windows-with-a-replication-set.18/
This guide will be updated as soon as possible.

In this guide I will show some simple steps of how to set up a MongoDB installation in a replication on Windows Server 2012.

For this setup, I used the following three servers that have Windows 2012 Standard edition installed.

bf-mongodb01: 192.168.1.42 / 4gb ram / 2 cpu
bf-mongodb02: 192.168.1.43 / 4gb ram / 2 cpu
bf-mongodb03: 192.168.1.44 / 4gb ram / 2 cpu

Workgroup: bf-mongodb

They all have to be in the same workgroup or in the same domain. If they are not then you have to add all the servers in your hosts file so mongodb knows how to connect to them.

Also, for this example I installed everything as “Administrator”. Depending on how you are going to use it I would suggest to make a non admin user to run all this.

So lets start!

Step 1: Download MongoDB (on all three servers)
MongoDB provides Windows installer packages, so simply download their msi file from their website http://www.mongodb.org/.
https://fastdl.mongodb.org/win32/mongodb-win32-x86_64-2008plus-2.6.3-signed.msi

Even if it does say ‘Windows 2008’ it does work perfect on Windows 2012!

Step 2: Install MongoDB
Just follow the pictures below to install MongoDB. You have to do this on all three servers.


Just press ‘next’.


Read the license and then tick the box you accept the license and press ‘next’.


Press you wish to install the “Complete” version.


Just press ‘Install’ to start the installation.


You should now have finished the installation so simpely press ‘Finish’.

Remember, you have to do this on all three of your servers.

Step 3: Create a database and log directory (on all three servers)
Create the following directories:
C:\basefarm\mongodb\data\db
C:\basefarm\mongodb\data\log

Step 4: Fix the Windows firewall (on all three servers).
Go to your “Control Panel” and then click on “Network and Internet”. Once there, click on “Network and Sharing Center” and then at the right side at the bottom click on “Windows Firewall”.

You should now see your Windows firewall like this:

On this window click on “Allow an app or feature trough Windows Firewall” your window will change and click on this window on “Allow another app..” and fill everything in as shown below.

If everything looks as above press on “OK” to close the firewall configuration window.

Step 5: Create a MongoDB config file (on all three servers)
Open a notepad and add the following information:
logpath=C:\basefarm\mongodb\data\log\mongod.log
dbpath=C:\basefarm\mongodb\data\db
bind_ip=0.0.0.0
replSet=bf

Once added, save the file as “mongod.cfg” in the directory:
“C:\Program Files\MongoDB 2.6 Standard\”
You should end up with
“C:\Program Files\MongoDB 2.6 Standard\mongod.cfg”

Step 6: Create a service that will automatically start MongoDB (on all three servers)
Open a Command Prompt and type the following:
sc.exe create MongoDB binPath= "\"C:\Program Files\MongoDB 2.6 Standard\bin\mongod.exe\" --service --config=\"C:\Program Files\MongoDB 2.6 Standard\mongod.cfg\"" DisplayName= "MongoDB 2.6 Standard" start= "auto"

This should create a service for MongoDB. If you did it correct, it should look like this:

Step 7: Start MongoDB (on all three servers)
Just restart the server and MongoDB should automatically start, so it is a good test that the previous commands worked.

Step 8: Go into the MongoDB shell (only on server one)
Go to “C:\Program Files\MongoDB 2.6 Standard\bin” and double click on “mongo”. A terminal window should open that looks like this:

Step 9: Create the replica set in the mongo shell. (only on server one)
While being in the mongo shell type the following commands:
rs.initiate()
rs.add("bf-mongodb02:27017")
rs.add("bf-mongodb03:27017")
cfg = rs.conf()
cfg.members[0].priority = 100
cfg.members[1].priority = 50
cfg.members[2].priority = 50
rs.reconfig(cfg)

Step 10: Test if your configuration is working. (only on server one)
in the mongo shell still type:
rs.status()

You should see something like this if everything is correct:

Congratulations, you now have successfully installed MongoDB on Windows and you have set it up in a replication :)! Now, let’s test that the replication works by creating a database on the master (mongodb01).

Step 11: Create a test collection with some data on the master (only on server one)
In the mongo shell type the following:
use basefarm
bf = { name : "basefarmblog" }
db.Data.insert( bf )
show dbs
show collections
db.Data.find()

You should see something like this:

As you can see “show dbs” did show you have a database Basefarm, “show collections” shows you have the collection Data and “db.Data.find()” shows that the Data collections contains the information “basefarmblog”.

If everything did work as intended, all this should have been replicated to your servers mongodb02 and mongodb03, so let’s test it!

Step 12: Check if the slaves have data (on server two or three)
Go to your server two or three and open a mongo shell by double clicking on the “mongo” file and run the following commands:
show dbs
rs.slaveOk()
use basefarm
show collections
db.Data.find()

If everything worked you should see the following:

The command “rs.slaveOk()” I used because this will you allow to read from the slave. By default this is not enabled.

Well, this was it. Everything worked and you can now use your MongoDB replica set for anything you like!

As always, if you have any improvements or see any mistakes, please let me know. I am always open to hear your ideas or to learn from you!

Configuring Windows Server 2008 R2 Features

At Basefarm we frequently need to ensure that many Windows servers are identical in terms of the roles and features they have installed. Adding features can be done in a number of ways. Mostly the graphical userinterface (Server Manager) is used. Or for large operations System Center or similar. I will show you how this can be done more easily using the command line. This method doesn’t require anything beyond Windows Server 2008 R2 (or later) and PowerShell.

The Server Manager module

The Server Manager module (introduced with Windows Server 2008 R2) has three very useful commands, they are:

  • Add-WindowsFeature
  • Get-WindowsFeature
  • Remove-WindowsFeature

Using these is simple. Start a PowerShell session with administrative privileges (Run As…) . Then check that the Servermanager module is available in your server:

PS C:\> Get-Module -ListAvailable

Get-Module -ListAvailable

This shows that the Server Manager module is available on our server but that it is not yet loaded into the PowerShell session. To load it (and make its commands available):

PS C:\> Import-Module Servermanager

Now the commands of the Server Manager module are available to you. Check which commands are exposed by the module:

PS C:\> Get-Command -Module Servermanager

Ok, we’re all set. Let’s use these commands!

HOWTO: Document what is installed

To see what is installed in a server use:

PS C:\> Get-WindowsFeature

Get-WindowsFeature

ooops, that’s a lot of text flying by on the screen! As you probably can guess only lines with [X] are installed. So we need to filter the list to only show what is actually installed, try this instead:

PS C:\> Get-WindowsFeature | ? { $_.Installed }

Get-WindowsFeature-installed

A nice clean list showing which features are installed on the server ;-), perfect for documenting your server(s)

HOWTO: Clone installed features to another server

As shown above it’s easy to list what is installed. But just having this list on the screen doesn’t make much sense, we need to be able to store this in a structured way so that we can use the list on another server to install the same features. PowerShell makes this very simple. We use the Export-CliXml cmdlet to save the information in a structured XML file:

PS C:\> Get-WindowsFeature | ? { $_.Installed } | Export-Clixml .\features.xml

The output from the Get-WindowsFeature cmdlet is saved in a structured way in the XML file features.xml. This file can now shared to other servers and used as input for the Add-WindowsFeature cmdlet!

HOWTO: Add features from another server (using XML file)

Start PowerShell with administrative privileges.  Now try this:

PS C:\> Import-Module Servermanager
PS C:\> Import-Clixml .\features.xml

Now you have the same list of installed features on the new server. But… this is simply a list in memory and on screen. The features haven’t been added yet. In order to do that we need to pipe the information into the Add-WindowsFeature cmdlet.

Before I show you how to do that there is one important thing I need to explain. When we exported the list of installed features we included all features that were marked as installed. As you saw in the output this resulted in a tree like structure where “[X] Web Server (IIS)” was on the top followed by “[X] Web Server” and so on.

That looks fine but if we use this as input for the Add-WindowsFeature cmdlet we will end up with more than we asked for. The reason is that when the top level feature such as “Web Server (IIS)” is choosen everyting underneath it will also be installed. And in order to keep our servers a lean as possible we do not want this! We need to go back and filter the output of Get-WindowsFeatre a little more. Try this instead of what I showed you earlier:

PS C:\> Get-WindowsFeature | ? {$_.Installed -AND $_.SubFeatures.Count -eq 0 }

Now the output will only contain information from the bottom-up so to speak. This works fine as input for the next server we want to make identical. Save the new list to a file:

PS C:\> Get-WindowsFeature | ? {$_.Installed -AND $_.SubFeatures.Count -eq 0 } | Export-Clixml .\features.xml

Now we can finally install these features in the new server:

PS C:\> Import-Clixml .\features.xml | Add-WindowsFeature

Est Voilá! The two servers now have the same Windows features installed.

As always with PowerShell, if your environment enables PowerShell remoting these commands could be executed on any number of servers from a single commandline. A Power(full)Shell that is!

Summary

This became a longer post than I intended simply because I wanted to explain the details about filtering the export. Here’s a Quick summary of the commands you use to export what is installed:

PS C:\> Import-Module Servermanager
PS C:\> Get-WindowsFeature | ? {$_.Installed -AND $_.SubFeatures.Count -eq 0 } | Export-Clixml .\filename.xml

Copy the file ‘filename.xml’ to a network share or other location where the next server can reach it, then do this on the other server:

PS C:\> Import-Module Servermanager
PS C:\> Import-Clixml .\filename.xml | Add-WindowsFeature

All features are installed on the new server without having to click-around in the graphical server manager! To verify what is installed quickly use:

PS C:\> Get-WindowsFeature | ? { $_.Installed }

I hope I have showed you that PowerShell is much better than giving your arms RSI using the mouse to handle feature installations!

SQL Server 2008 R2 setup fails due to invalid credentials

A colleague was trying to install a SQL Server 2008 R2 standalone instance today and he kept hitting a weird error when passing the credentials for the service accounts. He was running the setup as a local administrator on the server in question and he was trying to add a domain user as the service account.

The server in question was joined to the appropriate domain already and it had been checked that all the appropriate firewall ports were open. We knew that the user account he was using could query the domain structure as it was able to browse the domain to select the user account from the setup screen.

The errors we got for both accounts were (the text is truncated on the form)

The credentials you provided for the SQL Server Agent service are invalid. To continue…

The specified credentials for the SQL Server service are not valid. To continue…

We took a methodical troubleshooting approach and tested some other domain accounts which we knew were valid and were running other SQL instances elsewhere. These failed as well, meaning that we must have been encountering either some unexpected behaviour within this setup session, or we were being blocked from talking to the domain controllers in some fashion. We again checked the firewalls and they were confirmed as OK.

Then we went into the set logs. The summary log just showed that we had cancelled the installation. For example you see stacks like this which tells you nothing really

2011-09-12 15:59:21 Slp: Exception type: Microsoft.SqlServer.Chainer.Infrastructure.CancelException
2011-09-12 15:59:21 Slp:     Message:
2011-09-12 15:59:21 Slp:         User has cancelled.

However if you look in the detail.txt log file, contained one directory lower, you can scroll from the bottom up and find the actual cause of the problem in the page validation routines. It looks like this (I’ve removed the timestamps for better readability and also blanked all the identifying information obviously)

SQLEngine: –InputValidator: Engine : Attempting to get account sid for account DOMAIN\account
Slp: Sco: Attempting to get account sid for user account DOMAIN\account
Slp: Sco: Attempting to get sid for user account DOMAIN\account
Slp: Sco: GetSidForAccount normalized accountName DOMAIN\account parameter to DOMAIN\account
Slp: Sco: Attempting to get account from sid S-1-5-21-999999999-999999999-999999999-9999
Slp: Sco: Attempting to get account sid for user account DOMAIN\account
Slp: Sco: Attempting to get sid for user account DOMAIN\account
Slp: Sco: GetSidForAccount normalized accountName DOMAIN\account parameter to DOMAIN\account
Slp: Sco: Attempting to get account sid for user account DOMAIN\account
Slp: Sco: Attempting to get sid for user account DOMAIN\account
Slp: Sco: GetSidForAccount normalized accountName DOMAIN\account parameter to DOMAIN\account
Slp: Sco: Attempting to get account sid for user account DOMAIN
Slp: Sco: Attempting to get sid for user account DOMAIN
Slp: Sco: GetSidForAccount normalized accountName DOMAIN parameter to DOMAIN
SQLEngine: –InputValidator: Engine : Service Acccount Specified, Validating Password
Slp: Sco: Attempting to get account sid for user account DOMAIN\account
Slp: Sco: Attempting to get sid for user account DOMAIN\account
Slp: Sco: GetSidForAccount normalized accountName DOMAIN\account parameter to DOMAIN\account
Slp: Sco: Attempting to validate credentials for user account DOMAIN\account
Slp: Sco: Attempting to get account sid for user account DOMAIN\account
Slp: Sco: Attempting to get sid for user account DOMAIN\account
Slp: Sco: GetSidForAccount normalized accountName DOMAIN\account parameter to DOMAIN\account
Slp: Sco: Attempting to get account sid for user account DOMAIN
Slp: Sco: Attempting to get sid for user account DOMAIN
Slp: Sco: GetSidForAccount normalized accountName DOMAIN parameter to DOMAIN
Slp: Sco: Attempting to see if user DOMAIN\account exists
Slp: Sco.User.OpenRoot – Attempting to get root DirectoryEntry for domain/computer ‘DOMAIN’
Slp: Sco: Attempting to check if user account DOMAIN\account exists
Slp: Sco: Attempting to look up AD entry for user DOMAIN\account
Slp: Sco.User.OpenRoot – root DirectoryEntry object already opened for this computer for this object
Slp: Sco.User.LookupADEntry – Attempting to find user account DOMAIN\account
Slp: Sco: Attempting to check if container ‘WinNT://DOMAIN’ of user account exists
Slp: UserSecurity.ValidateCredentials — Exception caught and ignored, exception is Access is denied.
Slp: UserSecurity.ValidateCredentials — user validation failed

I’ve highlighted the problem section. As you can see our account has some permissions on the domain and successfuly gets the SID and various other tasks. However when it comes to the method

Attempting to check if container ‘WinNT://DOMAIN’ of user account exists

it fails…and moreover it then swallows the exception, and then to my amusement actually records that it’s swallowed the exception! To me this is really strange, I guess you could argue that the exception is security related and therefore is swallowed for security protection, but then it records what the error is in the log file, so this seems rather unintuitive to me. The bottom line here is that the account in question doesn’t have the specific privileges on our domain that SQL setup wants here, and so it fails and reports that the service account is invalid. In fact the service account is not invalid, the account used to lookup the service account is invalid. In my mind what should really happen here is that you should get a standard windows AD credentials challenge as the process has caught and handled an access denied error, meaning that it could present this information to the user. But hey, that’s just my opinion.

At the end of the day we changed the setup to use a different account with higher privileges (by running setup with a different logged on user) and everything worked just fine. The key here is that the error is misleading, it’s the interactive account under which you are running setup which has the problem, not the service account you’re trying to add.