Self Signing Certificates in Apache2

I found this terrific article explaining the process of self signing SSL certificates for Apache test servers. In my instance I couldn’t get a test site to work 100% as there were a couple of pages that were loading via SSL. By self-signing the certificate I could trick the pages into loading correctly.

http://www.crazysquirrel.com/computing/debian/apache-mod_ssl.jspx

When using the instructions above, be sure you note down all the paths of the files you are working with. Although the article is good – there are some small syntax errors when self-signing the certificate (the openssl x509 -in section)

Of course this process isn’t for public sites as there isn’t any CA actually signing the certificate for you – but it makes testing a site cheap and easy.

Trouble Installing FreeBSD ports

OK – I’ve been pulling my hair out all day trying to configure a FreeBSD server. Something to remember – ensure you update your FreeBSD ports before doing anything else!

Most older ports will install with no problems – but a lot of the ports require files that are no longer where they used to be. Unfortunately the port installation fails if it can’t find a file (in my case the php5-extensions port was failing on the PDFlib-lite-6 install… grrrr)

I found a great little article on updating your ports – http://sig9.com/articles/ports-howto

I didn’t worry about performing the portdb updates as I did a system search for the files and they weren’t found.

Anyway – update your ports and then run them. This way you know you won’t waste any time chasing an compiling old versions of required packages.

Make GNOME default at bootup

You need to edit the /etc/rc.conf file with the following line (of course after installing the GNOME packages)

gnome_enable="YES"

PPTP VPN not connecting (Error 800)

My users logged a call this morning complaining that they couldn’t connect to the corportate VPN – PPTP running on RAS (Microsoft Small Business Server 2003). I tried to connect and found the same thing.

After restarting the RAS services I started to troubleshoot.

I tried everything from disabling/enabling the Miniport driver to deleting the PPTP config and starting again – all to no avail.

Running the Microsoft Port Query tool (http://support.microsoft.com/default.aspx?scid=kb;en-us;310099) I found that the PPTP port 1723 was “ESTABLISHED” – this should be in “LISTENING” mode. This tells me that there is something running on the 1723 port that shouldn’t be – locking my users out.

I then used another great tool from sysinternals to find the process that was using my PPTP port. The tool is called TCPView and you can download it at http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx. TCPView told me that the connection on port 1723 was established by my SQL server and the exe that was using it was a BlackBerry service. I killed the process, restarted the RAS services and our PPTP VPN was now working.

Disaster Recovery Rehearsal

So I’ve spent the whole weekend performing our DR plan and there are a bunch of things to learn from the whole experience. I will be posting a more in depth look at the process and its floors over the coming week, however I thought I would quickly cap a couple of the issues I encountered.

- When restoring a full system to dissimilar hardware via Backup Exec, the only reasonable option is to use the Intelligent Disaster Recovery boot disk. Its almost impossible to restore the system in a timely fashion by rebuilding the machine and restoring data and services.

- The MS Exchange info store isn’t restored with IDR. You need to create a dummy store and restore the mail into that.

- Restoring Exchange takes for ever! Plan to sit and wait 10 hours for a small-ish info store to be recovered.

- Multiple issues with Symantec products after the restore was complete. As ridiculous as it sounds, restoring from an IDR doesn’t restore Backup Exec or any of the Symantec products. You need to manually remove the installation files and reg-keys and do a new install.

I will be covering the above points more closely in my follow up posts. Watch this space.

Deploying Office 2007 Compatibility pack via Group Policy

Since Microsoft released 2007 and the new .*x file format there have been some compatibility problems – sure you can save your documents in the “old” 2003 format – but you loose some of the extra functionality available for 2007 users.

Microsoft released an installer to resolve these problems allowing 2003 users to open 2007 formatted Office documents. I’m going to explain how to deploy this patch for you AD domain.

Firstly, download the FileFormatConvers.exe file from http://www.microsoft.com/downloads/details.aspx?FamilyID=941b3470-3ae9-4aee-8f43-c6bb74cd1466&displaylang=en

Create a directory C:\DEPLOY and place the .exe in there. Open a command shell and type the following:

C:\DEPLOY\FileFormatConverters.exe /extract:C:\DEPLOY\

This will extract the files to the directory and you will end up with two main files – 012Conv.CAB & O12Conv.MSI

You now need to place these two files onto a file server share where all your users have read permissions.

Now open up your Group Policy console and create a new policy – I reuse a policy called Software Deploy. Expand out the Computers Configuration and select the Software Settings > Software Installation.
Right-click in the right hand pane and select New > Package.

Browse to the package on the file share you are going to use and select the O12Conv.MSI file and choose OPEN. When prompted choose Assigned (you can also choose Publish but this option will not automatically install the software for your users – it will just make the package available for them to install). Once you have pressed OK you will find the package in your GPO.

Link this GPO to your OU where you keep you computers and do some testing. Read my previous posts on troubleshooting Group Policy if you have any dramas.

Easy as that. Deploying this package via Group Policy is the easiest way to ensure you won’t receive any more support calls complaining that your users can’t open 2007 formatted Office files!

WinINSTALL LE download has moved

The great application for creating MSI packages has moved from it’s most known download location. You can download it from:

http://downloads3.ondemandsoftware.com/download/installs/winstall90/WinINSTALL_LE.exe

I will be posting a tute on deploying Microsoft Office 2007 Compatibility pack shortly.

Tech.Ed Australia 2008

I have to apologize for the lack of posting the past couple of weeks. I was at TechEd in Sydney last week and have spent all this week trying to catch up.

I will have a bunch of really interesting posts on the cool things I discovered there – namely the advantages of Hyper-V, the clustering of Exchange 2007 (and how Microsoft implemented it) and also the to-be-released Virtual Machine Manager.

Watch this space!

Installing Backup Exec Remote agent on x64 System

Follow the following Symantec support article to install the Symantec Backup Exec x64 Remote Agent.

http://seer.entsupport.symantec.com/docs/280701.htm

I browsed over the article and didn’t follow it step-by-step and couldn’t get the installation to work. Take particular note to mapping a network drive – this was the step I ignored and the installation failed.

On the remote x64 computer, map a drive letter to the Backup Exec for Windows Servers media server using the following path: \Program Files\VERITAS\Backup Exec\NT\Agents\RANT64EX (the scripts do not support UNC paths).

Also note that this is a silent installation – you won’t receive any success/fail feedback. Just check the Add/Remove Programs control panel item to confirm the installation was successful.

Audit User Logon and Logoff

A quick and easy way to audit your users login times (and some other details) is by using this simple login script method.
Firstly, you need to build two .BAT file scripts and save them to some sort of Audit share on a server. (I suggest hiding the share with the $ so users can’t easily access the share).
You need to give all users write permissions to the directory as they will be running a script and updating a file.

logoffAuditScript.BAT

echo —- Logoff —- %username%, %computername%, %date%, %time% >>\\SERVERNAME\audit$\logoffAudit.txt

logonAuditScript.BAT

echo —- Logon —- %username%, %computername%, %date%, %time% >>\\SERVERNAME\audit$\logonAudit.txt

You need to add the logonAuditScript.BAT to the login scripts settings in Group Policy and obviously the logoffAuditScript.BAT to the logout scripts setting.

Basically all these batch files do is write a single line with the username, computer name, date and time to the .txt files specified in the script.
You can then open the text files with Excel and find out when your staff are logging in and out.

There are a lot more extensive audit login scripts available out there – however I found this a quick and easy option that satisfies my simple audit needs. The major draw back of this audit method is that it only runs when users login and logout… if users stay logged in for long periods of time nothing is logged. You can use Logon Hours within AD to force users to logout if necessary.