Office 2007 File Open/Save Dialog Issue

I have encountered a strange/annoying issue with Microsoft Office 2007 on a laptop with Windows XP SP3 as the operating system. This might affect other versions of Windows, however, I've been unable to confirm this as of yet.

Essentially, the problem was this: when using the file open or save dialog in the Office suite, clicking the drop-down menu at the top of the box in order to choose a location to save/open a file would result in a indeterminate progress bar appearing, with a title that stated "Initializing the Root Folders to Display".

This would remain for what seems like an eternity, before eventually disappearing and allowing the drop-down menu to finally render.

After doing some Googling around, it would seem this is a well known problem, caused by unreachable network drives. Here's a couple of pages, dating back to 2007(!), that discuss the issue:

http://benperove.com/howto/fix-initializing-the-root-folders-to-display-message/

http://forums.techarena.in/ms-office-support/652449.htm

And this is from Microsoft themselves:

http://support.microsoft.com/kb/313937


So, it would seem the issue is to simply not use persistent network shares, i.e. disconnect any network drives you might use. Although Microsoft provide some alternative solutions, I feel that they're missing the point: this is a Microsoft application failing to work "properly" with their own underlying operating system!

I have yet to decide on a solution for my own environment; as the network share resides on a small server that's not constantly powered on, a user logon script means the user will be bothered by a rather obtrusive DOS window while the relevant "net use" command times out attempting to connect. I suspect a simple shortcut will have to be the answer.

Fedora 11 on PPC Mac Mini

When I needed to set up a monitoring station for our developers, I found an old G4 (PowerPC architecture) Mac Mini in the office that was simply gathering dust.

While the rest of the office Macs were being either upgraded or freshly installed with Snow Leopard, it wouldn't be possible on this little device, as the PowerPC architecture isn't supported by the latest release of their operating system. I could have installed the previous iteration of OS X, Leopard, but I decided to have a crack at installing a Linux distro on the machine.

My work-supplied laptop is a MacBook Pro that I have configured as a dual boot machine; OS X and Fedora 11 are the two options presented by rEFIt when I power it on. Additionally, we use CentOS 5.x as our primary hosting platform and I consider myself a Red Hat man, so I opted to go with the PPC version of Fedora 11. I downloaded the PPC net installation ISO image and began. Unfortunately, the installation wasn't without difficulty, as I'll explain.

Display Issues

When I first attempted to boot the installation disk, I held down the "c" key on the keyboard to boot from the optical drive and I was presented with the Linux bootloader. I hit return to continue and, after some information about available memory was printed to the screen, the display went completely blank. I could still hear the disk being accessed, so this was clearly a problem with the display driver.

I hit CTRL+ALT+DEL, which the installer gracefully caught and restarted the machine. But, after holding down the "c" key again, the machine wouldn't display the bootloader; instead I just had a blank screen! Worried that I might have damaged the graphics card, I rebooted the machine again, this time letting it boot into the existing OS X install. No white screen and Apple logo appeared and for a short while I thought I was going to have to simply label the device as "bricked". However, the OS X log in screen eventually appeared and I breathed a sigh of relief!

After a few more attempts at booting the Fedora install disc, each failing to display anything, I tried a Debian PPC install CD, which gave similar results. I can't remember why I thought to attempt this next step, but it appeared to work: I completely unplugged the Mini from it's PSU and left it for a few minutes. When I came back to it, I was able to boot off the installation media and see the boot loader. I tried to launch the Debian installer, but this had the same problem of failing to render anything to the display.

I tried booting the installer several times, using various options to alter the output to the monitor; for example, disabling the framebuffer, forcing a low resolution, etc. However, none of these appeared to work either.

I was actually thinking of giving up attempting to install a Linux distro on the machine when I had another thought: I had up until now been connecting to the monitor (a ViewSonic VG2030wm) using a DVI cable. So I tried using the, older, VGA connection to the monitor, which required the use of an Apple DVI-to-VGA adaptor as the Mac Mini only has a DVI output on the rear.

To my surprise, this actually worked! The initial bootloader appeared at a much lower resolution, however, when I hit return to begin installation the system managed to display the installer.

I actually still had the Debian media in the machine, so I ran through a basic installation of Debian to see if I could actually get it to boot into a working OS. This was successful and I managed to log into the Gnome desktop without any problem.

LVM Issues

I was still determined to install Fedora 11 on the box, so I rebooted the machine to attempt this. With the Mac Mini connected to the ViewSonic using the VGA cable, the installer launched without any issue and I proceeded to install the OS.

Everything was going well, until I reached the partitioning stage. As there was already a Apple BootStrap defined from the previous Debian install, I simply deleted the Linux partitions and created an LVM based install, with a partition for /boot, one for the root file system, one dedicated to swap, with another dedicated to be used as an LVM physical volume. After defining this partition scheme and all my logical volumes, I tried to continue to the next step in the installer, however, I was presented with the message: "You have not defined a boot partition".

After some reading through the Fedora PPC howto guide, I decided to recreate the Apple BootStrap partition. so I simply removed all the partitions and started from scratch. I created a 1MB Apple BootStrap partition (as suggested by the howto) and the rest of the partitions/volumes as before.

This time, when I hit "Next", the installer began to create all the relevant partitions and logical volumes. But I was again presented with an error; this time the installer had failed to create the volume group. This meant I had to exit the installation and reboot the machine.

After the reboot, I booted into the installer again, and hit CTRL+ALT+F2 to bring up another virtual console; this one is a basic shell you can use to assist in troubleshooting installations. Running the LVM command I inspected the configuration of the system. I immediately found that the installer had not actually run the appropriate commands to turn the specific partition into an LVM physical volume. I ran this command manually (pvcreate /dev/hda4) and then created the volume group too.

I then switched back to the installer console (ATL+F6) in an attempt to use the partitioning tool to assign the already existing partitions (/boot, root and swap) to their relevant roles and create the logical volumes I wanted to have. Unfortunately, the partitioning tool didn't appear to see the Apple BootStrap partition(s) that had been created previously and, as I suspected, I was unable to progress through the install as I was presented with the "You have not defined a boot partition" message again!

I could not see a way to get the system working with logical volumes and, by this time, I just wanted to get a working Fedora install, so I resort to merely creating basic partitions for the file systems I wanted. There is no room in the Mac Mini to install additional HDDs, so I wouldn't have the opportunity to extend my file systems in the future anyway!

After settling for this more basic configuration, the installation progressed without any further problems and I eventually managed to boot into a working install of Fedora 11.

Here's a pic of the machine in-situ; note the monitor in the picture is not the ViewSonic monitor that I described having trouble with in the article:


Summary

In summary, the issues I had with installing Fedora 11 on an Apple Mac Mini were:

• I experienced issues with ViewSonic VG2030wm monitor; the installer wouldn't display when using a DVI cable to connect to the screen. I needed to use a VGA cable in conjunction with a DVI-to-VGA adaptor.


• Issues creating logical volumes. It appeared that the installer had not executed the pvcreate command before attempting to create the volume group. I ended up resorting to a system based on standard partitions.

I hope this post can help others attempting to install Fedora (or any other distro) on the G4 Mac Mini. If nothing else, at least I can come back to it, should I need to install Linux on an old Mac Mini again.

Wireless Security

Wireless technology based on the various IEEE 802.11 standards is becoming ubiquitous in the home and workplace. While most offices will have I.T. staff who understand the security implications of implementing a wireless network, there are still many businesses that have poorly configured equipment, resulting in a vulnerable system.

If there are businesses still in the dark when it comes to wireless networking, what about the average home user? Almost all wireless access points purchased by consumers will work "out-of-the-box", providing an easy way to extend the range of your home network. However, it is highly unlikely that the configuration used will include any network authentication or encryption, allowing anybody to connect and use the networks resources (Internet, file-shares, printers, etc.). If the unauthorised user is of the Black Hat persuasion, they may attempt to compromise any system they find on the network - a home P.C. would provide a wealth of information about the owners of the network.

In order to protect a wireless network, it is necessary to understand the configuration options available.

Change Default SSID

The Service Set Identifier (SSID) of a wireless network is the network name - on most access points, the default is simply the make and/or model of the device. It is prudent to change this to something unique and that doesn't make it possible to identify the owner of the wireless network.

Disable SSID Broadcast

It is possible to disable the broadcast of your SSID - however, due to the nature of wireless networks, it is still possible to extract this information from the packets of data being exchanged between machines on the network through the air. Therefore, this is not a security option and can be disregarded when configuring a router.
In fact, it has been shown that configuring a wireless network to not broadcast it's SSID can actually have an impact on it's performance - read this pdf.

MAC Filtering

All network adapters have a quasi-unique address encoded into the hardware that takes the form xx:xx:xx:xx:xx:xx, with each "xx" a hexadecimal value between 00 and FF - this is the card's MAC address. It is possible to configure most wireless access points with a list of MAC addresses, and either permit or deny access to network cards with corresponding addresses. However, as it is possible to change the MAC address of a network card using a machine's operating system, this would not take long for a determined hacker to bypass.

WEP - Wired Equivalent Privacy / Wireless Encryption Protocol

Despite the name, WEP does not offer the same level of privacy as a wired network - in fact, it's far from it. Essentially, WEP encrypts traffic on a wireless network using either a 40 bit or 104 bit key. Client machines can also be forced to authenticate to the network using the key (Shared Key authentication); however, it is more secure to have no network authentication (Open authentication), and rely on the encrypted traffic to secure access to the LAN's resources. This may seem counter-intuitive, but it is very easy to derive the network key by capturing the entire authentication "handshake" that occurs between the access point and client machine.
WEP has been proven to be extremely easy to crack, in fact, this author was able to crack a network that he had "protected" using WEP with a 40 bit key in approximately 10 minutes. Where possible, WEP should be avoided in favour of stronger forms of authentication and encryption.
To find out more about WEP, follow this link.

WPA2 - Wi-Fi Protected Access

WPA was created after the flaws in WEP were uncovered - it implements most of the IEEE 802.11i standard - it was originally intended as an temporary solution while the standard was still in it's draft stages. A second version, WPA2, implements the entire standard, but does not work with some older network cards. Networks that implement either of these benefit from much stronger client authentication and data encryption than those that rely on WEP. To authenticate to the network, WPA/WPA2 provide a myriad of Extensible Authentication Protocol (EAP) options, which allows authentications to be passed off to a dedicated machine - each user of the network can use a different set of credentials. However, this is not practical for the home, or for small businesses, so another method of authentication is available - the Pre-Shared Key (PSK). This just requires that an arbitrary, pre-determined, key be input to each station on the network, which is then used to authenticate when joining the wireless LAN. When using this mode of authentication, it is important that the key used should be composed of at least 20 characters, and consisting of lower and upper case characters, numbers and symbols (e.g. !,=,+) - otherwise, the key is vulnerable to discovery by brute-force attacks.

It is possible to implement any combination of these methods to protect your wireless network; apart from WEP and WPA, which are mutually exclusive. However, as mentioned previously, MAC filtering and disabling the SSID broadcast are extremely easy to bypass, and should only be used in tandem with WEP or WPA, if used at all. An optimal configuration for a consumer would be to simply change your SSID from it's default value and implement some form of WPA-PSK; ideally WPA2-PSK, as long as all your hardware supports it.

If you possess both the knowledge and resources, it is highly recommended you opt for the WPA2-Enterprise solution using the EAP-TLS method of authentication. This is the most secure of all the EAP methods, using SSL certificates to authenticate the client machines to the network, but also the server to the client; preventing man-in-the-middle style attacks where a malicious user sets up a rogue AP. This method requires the most configuration, as a certificate authority must be use to issue certificates for all the devices that wish to use the wireless network.
The other EAP methods are slightly easier to configure, however, it's important to note that if you intend to use MSCHAP as the inner authentication method, you will need Active Directory as your directory server. This is because the passwords supplied by an MSCHAP client are an NTLM hash, which can only be interpreted by Microsoft's directory service.

Wireless security is an important subject, however, it's not one that's well understood by most end-users. Hopefully this article will have helped explain the options available to people. Feel free to contact the author if there are any questions you may have regarding the subject.

Microsoft SQL Server 2005 DB Restore Issue

After a database backup that was taken from a Microsoft SQL Server 2000 instance was restored to a SQL Server 2005 instance, I experienced an issue where the name of the user that owned the database previously is prepended to all the table names. Check out the image below of the Object Explorer to see what I mean, it's a restored Confluence database; as you can see, "nconfluenceuser" is part of the table names. Usually, this would be "dbo" (DataBase Owner).



This caused an problem for the Confluence instance that attempted to use the database, because none of the queries performed against the database worked - they all failed with an "table does not exist" error.

To get around this issue, I performed the following steps:

1. Created a new database in the Object Explorer.


2. Right-clicked the DB, selected "Tasks", then "Import Data..." - this presented me with the Import and Export wizard.


3. As I was presented with the wizard's welcome screen, I had to hit "Next" to progress to the "Choose a Data Source" screen. Here you select the data source, server and database to import from. As my restored database was on the local machine, the "Data Source" and "Server Name" fields already had appropriate values; all I had to do was select the database from the drop-down list marked "Database".


4. Hitting "Next" took me to the "Destination" screen, which was already filled out correctly, because of how I kicked-off the wizard (via the destination database's context menu).


5. For the next step in the Wizard, I chose the default selection of "Copy data from one or more tables or views" before clicking "Next".


6. Now for the important bit; the "Select Source Tables and Views" step. Here I had to click the "Select All" button, then edit the "Destination" fields for all the tables; removing all the text prior to the table name. After moving down to the next table, the wizard ensured that the edited destination was correctly formatted. See the below pic for an example:
   
   These were the only modification I made in this step, I didn't change any of the other options present


7. I clicked "Next" a couple more times, which allowed me to review the pending transactions, before I clicked "Finish" to finally perform the import; this could take some time, depending on the size of the DB to import and the speed of the machine.


8. After it had finished and I closed the wizard, I was able to see that the newly created DB no longer had the "nconfluence" username prepended to it, but "dbo"; see the below picture.
   


9. My final step was to create a user for Confluence to bind to the database as, granting the account "dbo" privileges over the imported DB.

OS X Partition Capacity Issue

I ran into a bit of a problem with my dual boot MacBook Pro the other day. I was booted into OS X, and I was prompted by the operating system to install a bunch of system updates that had been released since I last used the OS. When I attempted to download and install them, I was informed that I did not have enough free disk space. This surprised me, as I had installed OS X onto a 20GB partition, and I had not installed any office suite or other large applications; I perform all my work when booted into Fedora, only using OS X for web browsing - checking email, online shopping, BBC iPlayer, You Tube, etc.

I checked my hard disk usage, and it only amounted to just shy of 15GB ; I would have thought this should have been plenty of space to download and extract the updates I had pending. However, as OS X didn't seem to think so, I was stuck. I'm quite concerned with IT security, so you can imagine my dismay at realising I would be unable to keep my operating system up to date!

Monolingual - A Quick Fix

A colleague of mine suggested I try Monolingual - it's an application that allows you to remove unneeded localisation data from your OS X installation, as well as any unnecessary binaries that are compiled for different architectures (Intel, PowerPC, etc.). Unfortunately, I was only able to clear a couple of hundred megabytes of data, so I was still unable to run the system update, which left me with the unenviable task of trying to increase the size of the OS X partition.

Before I continued, I ensured that I had backed up all of my important data off the laptop - messing around with partition tables can leave your machine unusable, not to mention the possibility of accidentally deleting a partition!

Partition Resizing

My next step was to boot from the OS X installation DVD, and attempt to use the Disk Utility to modify the partition table. I had a second HFS+ partition positioned directly after the OS X partition - the idea being that I could use this partition to share files between both operating systems on the disk. The Apple Disk Utility allows you to resize HFS+ partitions, however, I could not shrink the second HFS+ partition without leaving the recovered space after the partition, which then meant I would be unable to reassign it to the first HFS+ partition. This meant that I had to delete the second HFS+ partition, resize the first, and then recreate the second partition in the space remaining.
When I tried this, however, the Disk Utility simply hung while displaying the message "Preparing to delete volume"; I did actually leave it "preparing" for a good hour while I had dinner, but no progress seemed to have been made when I returned, so I cancelled the operation. As the Disk Utility seemed unable to remove the partition, I booted off the Fedora 9 installation DVD into rescue mode and used the GNU parted tool to remove the second HFS+ partition - which worked without complaints. I restarted the machine and booted off the OS X install DVD to try and resize the OS X partition with the Disk Utility, however, this hung as before; displaying the message "Preparing to resize volume".

I could have tried using GNU parted to resize the partition, but this probably wouldn't have worked, so that left me with one more option before I would have to bite the bullet and perform a complete reinstall of both operating systems: I deleted the OS partition using GNU parted, and then attempted to run through the OS X install, creating a new partition in the space available at the beginning of the disk. The Disk Utility, however, refused to create any new partitions on the disk... I was going to have to wipe the disk completely and start from scratch!

Complete Reinstall

After having made the decision to completely reinstall, it was a fairly painless process. However, I look the opportunity to install Fedora 9 instead of Fedora 8.

Once I had my laptop "fully armed and operational" again (well, at least with two operating systems installed), I checked the OS X partition to see just how much space a fresh install of OS X would consume. I was extremely surprised to find that 11GB of valuable hard disk space had been used - this is as much as a fresh install of Vista! Now admittedly, there are probably quite a lot of compatibility libraries to allow Rosetta to work, as well as binaries for the various architectures that OS X supports, but this still seems like a large amount of program data!

Anyway, the moral of this story is to ensure you leave plenty of space for OS X, should you be partitioning your hard drive before installing the operating system. This won't affect most Mac users, just those of you that either partition your disk for whatever purpose.

--

This article originally appeared here.

Forwarding Traffic with IPTables

The netfilter/iptables tools for Linux can be used to route traffic destined for a particular host to another. An example where this might be useful is when migrating a service from one host to another and waiting for DNS changes to propagate, you want to ensure that all traffic destined for a particular host name will be serviced by one particular machine.

Say you have a machine called alpha, with IP addresses 10.0.0.30 and 10.0.0.31 and you wish to route traffic destined for 10.0.0.31 to a different machine, called beta, that has the IP address 10.1.1.40, essentially using the first machine as a "middle-man" for requests destined for a particular host name. The effect will be that, no matter what machine the requests end up at initially, they will always be serviced by the second machine.

This is by no means the most elegant method for redirecting services; HTTP Redirects can generally be used with websites. However, sometimes this method can be useful.

To implement this using iptables, the commands below would need to be executed as root on alpha:


echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -A PREROUTING -t nat -d 10.0.0.31/32 -j DNAT --to 10.1.1.40
iptables -A POSTROUTING -t nat -d 10.1.1.40/32 -j SNAT --to 10.0.0.30

The first line tells the kernel to allow forwarding of IP packets; without this, the other commands will be useless. The first iptables rule mangles packets of data destined for 10.0.0.31 before any routing decisions take place by changing the destination IP to 10.1.1.40, which causes the redirection of traffic. The second rule takes effect after the traffic has been routed, ensuring that return traffic travels back through alpha by changing the source IP of packets destined for beta to 10.0.0.30.

If you wish to just forward traffic destined for one particular port, for example a mysql database on 3306, you would use the -p and --dport arguments:


echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -A PREROUTING -t nat -p TCP -d 10.0.0.31/32 --dport 3306 -j DNAT --to 10.1.1.40
iptables -A POSTROUTING -t nat -d 10.1.1.40/32 -j SNAT --to 10.0.0.30

By using multiple PREROUTING rules, you can specify multiple ports; one for each of the services you need to forward traffic for.

--

This article originally appeared here