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 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!

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

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

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

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 }

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:

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

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:

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

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)

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.