IIS and those pesky Flash files

Doesn’t it drive you mad when you set up an IIS server in Windows and you forget to add Flash files to the MIME types? You end up debugging what you think is some scripting problem only to remember about 2 hours later that IIS’s file support out-of-the box leaves a lot to be desired.

Well, I can’t stop you or me not wasting time, but I thought that I’d collect up file types here for reference:

Extension: .flv
Content type: video/x-flv

Extension: .7z
Content type: application/x-7z-compressed

WIM – Windows Image File
Extension: wim
Content type: application/octet-stream

Install vim on an Ubuntu server and desktop

I’ve grown quite fond of vim over the past couple of weeks. After learning and re-learning the shortcut keys, I think that I’m finally on my way to knowing what the hell I am doing!

Anyway, after working on it – I’ve found gVim to be great.

To install, just run:

<code>sudo apt-get install vim-full</code>

This includes syntax highlighting and other neat stuff. If you want to gegt the syntax highlighting on the server, just run:

<code>sudo apt-get install vim</code>

Yes, that’s right – no extra bits.

Getting that SQL Server 2008 to Work out of the box

I had to set up a new SQL Server database, which I haven’t done in a while as I tend to focus my efforts on mySQL. Nevertheless I needed to get grip on a new site to migrate.

After setting most things up, I managed to get to a point where the database wasn’t starting.

Microsoft OLE DB Provider for SQL Server error ‘80004005’

[DBNETLIB][ConnectionOpen (PreLoginHandshake()).]General network error. Check your network documentation.

I really love unhelpful messages. Anyway, after some head scratching I foundĀ an article on on the Microsoft Forums from a chap with a similar issue.

To fix the problem, I loaded up the SQL Server Configuration Manager, and expanded SQL Server Network Configuration. Under Protocols for MSSQLSERVER (this is the instance name of the server), I enabled TCP/IP. The error went away. Tada!

I suppose it would help to read the documentation thoroughly – but I got to where I needed to be anyway. I imagine that it makes sense to disable TCP/IP connections until you’re happy that the server is secure. Even so, I was making connections from the localhost, so I would have expected it to work.

Migrating Users on Windows 2003 Domains

Steve and I have often been stumped with migrating users simply because there’s not an easy to follow “how to”. So here’s an easy-to-follow “how to”.

To migrate users across domains, you will need the Active Directory Migration Tool from Microsoft. Install this on both servers.

First thing’s first – you’ll need to create a trust between the two domains. To create a trust:

  1. Set up a secondary DNS zone on each domain controller you plan to use. You need to enable Zone transfers on the DNS servers, and then create a secondary zone on each server of the other domain.
  2. Create a domain admin user account on each domian with the same username and password.
  3. On one of the servers you are working on, access Administrative Tools > Active Directory Sites and Trusts. Right-click on the domain you are using – and then click properties. From here, you can create a two-way trust between each domain.

Now we’re ready to migrate users. If you need the passwords migrated as well, you will need to complete these steps. If not – skip to the next part.

  1. On the source domain controller, you will need to create a key file. Open up the command prompt and type in the following (replace with your own domain and .pes file):
    <code>admt key /option:create /sourcedomain:your.domain /keyfile:C:\MyKey.pes /keypassword:*</code>
  2. Once the key file has been created – you need to install the Password Server. Run

    to install. During the installation, you will need to use the key file that we created in the previous step. You will also need to specify a domain administrative account to run the service.

  3. Now copy the keyfile to the target server. We need to manually import the key so that the passwords will transfer:
    <code>admt key /option:import /sourcedomain:<em>your.domain</em> /keyfile:<em>C:\MyKey.pes</em>/keypassword:*</code>

    Enter the same domain and pasword you used in step 1.

  4. On the source domain controller – open Active Directory Users and Computers, and double-click on the BUILTIN\Administrators group. Add the target domain administrator to the group (eg. targetdomain\administrator).

Now to migrate those accounts! Woo!

  1. Open the ADMT tool from Administrative Tools
  2. Right-click on the Active Directory Migration Tool folder
  3. Click User Account Migration Wizard
  4. Select the source and target domain
  5. Select the users either with a file or though the AD tool
  6. Select the target OU where you would like the users to be migrated to in your new domain
  7. Select how you would like passwords to be handled. If you are migrating the passwords, you will need to start the Password Migration Server Service on the source domain now.
  8. Answer the remaining questions appropriately.
  9. Job done!

The new user accounts will appear in the new domain.

Simple User Logon Logoff Logging on a Windows Domain

I like simple scripts, and this one is so obvious – I wonder why I didn’t think of it:

First, create a folder on your server, and share it as logon$. Make sure that users are given read and write access in the share properties, and in the folder security settings.

Create the following logon scripts and add them to the logon / logoff scripts as appropriate. Both scripts are ONE LINE ONLY.


echo logon,%COMPUTERNAME%,%USERNAME%,%DATE%,%TIME% >> \\server1\logon$\Logon.csv


echo logoff,%COMPUTERNAME%,%USERNAME%,%DATE%,%TIME% >> \\server1\logon$\Logon.csv

Once done, you can load the file into a program such as Excel and easily manipulate the data to find what you are looking for.

Naturally, change the name server1 to your server name. It’s a simple way to log users accessing workstations so that you know who as logged on where.

I was considering doing the same with a database and VBscript – which would inevitably slow down the logon process. This should make things wonderfully simple.

I settled on keeping the log file the same for logons and logoffs, as it seems sensible to track these in the same file. If you seperate them and say, want to find out how long a user has been logged on for, then you have to start dealing with too many seperate files.