For this example we can assume a few things:

1. You have already set up a headless VirtualBox server
2. You have already created a Virtual Machine instance. For this sample, we will call the Virtual Machine “MyVM”.

Believe it or not, setting up bridged networking to allow your VM to access your network is pretty simple and completed by issuing the following VBoxManage command in a terminal window.

Command: VBoxManage modifyvm “MyVM” –nic1 bridged –nictype1 82540OEM –bridgeadapter eth0

Break it down

To understand a bit more about what’s happening here, let’s break down the command string from the beginning.

VBoxManage - This is the command line utility used to access, control, configure and manage your VirtualBox Virtual Machines.

modifyvm - This command allows you to make changes to the properties of a Virtual Machine, including the amount of memory assigned, nic interfaces, Virtual device boot sequence, number of CPUs, etc. It can be compared to the Settings dialog of the VirtualBox Graphical user Interface. The command line version, however, offers additional advanced options not found in the GUI.

Note: the VM must be registered within VirtualBox, but must not be running

“MyVM” – This is simply the name of the VM you want to modify.

–nic1 bridged - The –nic1 parameter is used to set the type of networking your VM should use for each of the it’s virtual network cards. You can have more than one network card in use for a VM so the paramater is written as –nicX where X is the network card being targeted. Here, “–nic1″ is the first network interface, –nic2 would be the second and so on. This portion of the command string is setting the type of networking on the first interface to “bridged”.

–nictype1 82540OEM – The –nictype1 parameter allows you to specify which networking hardware VirtualBox should emulate for the VM’s virtual network cards. Here we set the networking hardware to emulate an Intel PRO/1000 MT Desktop card or 82540EM.

–nictypeX follows the same sequence numbering and –nicX for multiple interfaces where –nictype1 is the first virtual card, –nictype2 is the second and so on.

Note:  The following is a list of the available nic hardware types and the associated ID recognized in VirtualBox.

• AMD PCNet PCI II = Am79C970A
• AMD PCNet FAST III = Am79C973 (the default)
• Intel PRO/1000 MT Desktop = 82540EM
• Intel PRO/1000 T Server = 82543GC
• Intel PRO/1000 MT Server = 82545EM
• Paravirtualized network adapter = virtio-net

–bridgeadapter1 eth0 – Finally we have the –bridgeadapter paramater. This is the only part of the command string that references a part of the VirtualBox host and tells your VM which physical host adapter to pass it’s traffic through.

Again, this uses the same sequence numbering as nicX and nictypeX for multiple interfaces. Here, we are setting the bridgeadapter for our first virtual network card to use the eth0  interface on the host. Note that is eth zero, as in the number and not the letter O.

And that’s it. Restart your VM and you should now have a working bridged network interface for you VM with full network and internet access.

Photo: Wally Gobetz

Editors Note:

While I was writing this, the solution to my problem struck me unexpectedly. Click here to skip the drama and jump right ot the solution.

Originally, this article started out as a complete rant and cry for help. I started to write about the failure and frustration of the installation and network configuration of a virtual machine in VirtualBox 3.0.4.  It just would not work. The problem, as it turned out, was that I was over thinking the process. BUT, that is not completely my own fault.

See, here’s the problem. Before starting anything new, I read, research, and read some more to get as much of an understanding as I can on the subject. In this case, the official documentation of VirtualBox 3.0.4 in my opinion is incomplete and did not include some of the specific details that would have made this setup much less painful. Combine that with the piles of information regarding networking configuration in previous versions, and it’s easy to get some wires crossed. Networking in version 3.0.4 was largely improved and simplified, meaning a lot of the information available online, in forums, on blogs, etc, is irrelevant to the new version and the current documentation does not do a great job of explaining the changes and how to set up networking, specifically bridging, in the new version.

In my research and troubleshooting I’ve seen many others who describe the same problems I had while trying to set this up under version 3.0.4, so in the spirit of passing on my experience and what I learned from it, I am going to keep my original writing here so you can see what I was doing and why it was wrong. If you want to skip to the solution, please click here.

The Original Post (the wrong way)

Ok, here it is. Frustration has finally gotten the best of me and I have no  idea where to go from here. What am I talking about, you ask? I’m talking about setting up a Virtual Machine (VM) using VirtualBox 3.0.4 on a Windows XP Host.

Let’s take a look at what has brought me to this state of utter frustration.

A while back, I downloaded and installed VirtualBox to set up VMs to test and play around with some different Operating Systems and Software. To be honest, it works Great for that purpose. But now, I want to take my virtualization experience to the next level and have been thinking about installing FreeNAS in a VM to serve as a NAS solution and making it available to all PCs  across a production LAN.

The Parts:

I have a Windows XP sp2 machine sitting at home that is not getting much use that would be perfect for trying this out.

Specs:

• Windows XP sp2
• 4 Gigs of RAM
• 500 Gig HD
• Intel Quad Core Processor
• Single on-board G-bit network adapter.

I know there is a bit to cover and become familiar with when setting out to connect a Local LAN to a VM in the same address space, so I did my research first.

I downloaded and printed the VirtualBox user manual. Reading through it I highlighting the parts that I thought were important or significant. The documentation seems a little incomplete and is NOT all that well written for someone just getting started.  There are no guides or instruction that specifically marks the steps for setting up the different types of network options. So I figure, fine! After reading the manual, I should have some idea of the basic requirements. I can just do a search on the net and piece together the rest of the information.

That sounded like a good idea a first, but in practice..not so much. The web served up a LOT of information related to VirtualBox network bridging and configuration. The problem is that a lot of it was contradictory and there is almost no information specific to version 3.0.4. I read through forums, blogs, papers and anything else that looks like it might help. In the end, nothing was extraordinarily helpful.

Host OS (Windows XP)

Physical Network Adapter: Local Area Connection (2)  NVidia NForce Network Controller (Bridged /Connected)

Virtual Host Adapter: VirtualBox Host-Only Network

Bridged Adapter (Local Area Connection (2) + VirtualBox Host-Only Network):  Network Bridge (Network Bridge)

Note that the Host adapters were set to Compatible Mode as recommended by several forum posts and blogs.

Screen netsh bridge compatmode

Guest OS (FreeNAS/ Linux Based)

Network settings for the guest were set up using

Adapter Type: IntelPRO/1000 MT Desktop. This was selected based on recommendations that appeared repeatedly in forums and blogs.

Attached to: Bridged Adapter

Name: MAC Bridge Miniport – This was the only selection available in the menu.

VM Network Configuration

Installing the Guest

During the installation of  FreeNAS, I used static IP information

• IP Address: 192.168.15.115
• Netmask: 255.255.255.0
• Gateway: 192.168.15.3 (LAN Router private IP)
• DNS Server: ISP DNS IP

Errrrrrttttttt….

(that’s my best screatching to a stop text effect).

It’s amazing how when you step away from a problem and look at it from another angle, how easy the solution comes to you. By writing out my thoughts here and stepping through all the little details, something hit me and it is THE key piece of information that is missing between setting up older versions of VirtualBox and Version 3.0.4.

There were a number of references that said networking and bridging in the new version was completely refigured and the process was very simple. Basically, just create a bridge – But no details were ever provided on what that meant exactly. Based on all the “old” information and lack of new detailed explainations, I figured it meant to create bridged connections on the host and use that as the Guest bridged adapter. What if the solution is even simpler  than that. It’s worth a try…Soooo

I went back to my Host settings (Windows XP Network settings) and tore down the bridge and restored my original adapters and IP information. Now I only have Local Area Connection (2) and VirtualBox Host-Only Network shown. From here I went back to the VirtualMachine Network settings and listed in the “Name” menu instead of  “MAC Bridge Miniport” I now had the two Host adapters listed. (Local Area Connection (2)  and VirtualBox Host-Only Network).

I selected the physical Host Adapter (Local Area Connection (2)), restarted the VM and to my amazement.. It all worked.

(the right way)

In the end, this is how you set up bridged networking between Virtual Machines and the LAN with VirtualBox 3.0.4

Windows XP Hosted VirtualBox – using the GUI:

Host Network Settings:

This part is easy. Do nothing. That’s right, nothing! No changes are necessary for the host’s interfaces or network settings (as long as you already have a working interface).

DO NOT create or bridge any interfaces on the host system. Leave the network interfaces on your host OS (physical) alone.

Guest Network Settings:

Start VirtualBox and highlight the Virtual Machine you want to modify from the list on the left. Once highlighted, select “network” under the “details” tab on the right.

Select VM

You should now see a window displaying the Network settings for your VM.  From here, the Adapter 1 tab and make sure the “Enable Network adapter” checkbox is selected.

Next to “Adapter Type” select “Intel Pro/1000 MT Desktop” or “Intel Pro/1000 MT Server” from the menu. These have a higher rate of success when used in this way. I had some trouble with the PCnet II and PCnet III adapter Types.

Select Adapter Type

Next to “Attached to” select “Bridged Adapter” from the menu.

Select Bridged Adapter

Finally, next to “Name” select your Host system’s network interface from the menu. In this case, my host system interface is the on-board “NVIDIA nForce Networking Controller”. Your options will likely be different based on the interface installed of in use.

Select Host System interface to be bridged.

That is all there is to it. Just hit the “OK” button in the main settings window and start your VM. As long as the Guest OS on your VM hs been configured with the correct IP/network information for your LAN, you should now be able to ping and access it from any PC on your network.

Conclusion: So simple, even a Caveman can do it!

Initial frustration aside, in the end, I really have to give props to Sun/VirtualBox for actually making this incredibly simple to set up. On the other hand, they lose points for failing to make this clear in the documentation.

Final Note:

Since posting this, VirtualBox 3.0.6 has been released. Considering how easy this is to set up in 3.0.4, I can only guess that it is just as simple in 3.0.6. After all, it would not make much sense to make any changes that would make the process more difficult.

I hope you find this information helpful or useful and hopefully can use it to avoid the mistakes I made. Have a question, suggestion, better way of doing this or just want to leave some feedback? Please leave a comment.

Updates:

VirtualBox 3.0.6 – Confirmed / Working
VirtualBox 3.1.8 – Confirmed / Working

It’s no secret that I am a fan of Ubuntu Linux. BUT.. one of the annoying things about using Ubuntu is trying to set up a network printer on a desktop or workstation. Regarding nearly all administrative tasks under most Linux systems that would require root permissions, Ubuntu has done a nice job of making it possible to operate a system as a “normal” user without elevated privileges, and then easily gain the elevated (root) privileges temporarily assigned to complete some specific administrative task. Ubuntu detects when a user is trying to do something requiring the elevated (root) privileges and pops up a small window asking for the current user’s password to gain the required permission. All the magic happens behind the scene and the user never has to issue a text command. It wasn’t long ago that users would have had to open a command terminal and issue all the instructions by hand. Well.. we’ve come a long way.. With the exception of installing a network printer. For some reason, when installing a printer in Ubuntu, the user is not prompted with the normal su password pop-up that presents itself for all other administrative tasks. Instead, the CUPS system prompts the user for the root password – and under Ubuntu, there is no root password by default meaning that root can not complete any direct action requiring a password. In fact, root can not log directly into the system at all. Fortunately, the solution is fairly easy.

The Solution

Do not try to install a printer from System > Administration > Printing menu. It won’t work. Sure, it will allow you to go through the wizard and give you the false impression that you’re actually accomplishing something – until you reach the point where a driver needs to be installed and you’re prompted for the root password. Instead, go to the Applications > Accessories menu and select Terminal.

Once the terminal window opens, issue the following command

sudo system-config-printer

The next line in the terminal window will ask for your password. Type in your user password and hit enter. If all is correct, the printer setup and configuration window will open with elevated privileges enabled and you can finish installing and setting up your new printer from comfort of an easy to use GUI.

Sample Setup

Lets take a few minutes and walk through the process. In this example, I will be setting up a Dell 1700 Laser Printer in my Home Office. Before you get started, you will need to know a few things about the printer first.

IP address: What IP address did you assign to your network printer?

RAW Port: Typically, the default RAW Port is 9100. If you assigned something different you’ll need to remember what it is.

Open a Terminal Window: System > Administration > Terminal

Terminal Window

Issue the command “sudo system-config-printer” (no quotes)

sudo command

Provide your password when prompted.

sudo password

The Printer Configuration window should have opened

Printer Configuration

Press the “New” button to add a new printer.

The “New Printer” window will open after a brief search displaying the “select Device” panel

Under the “Devices” list, expand the “Network Printer” selection by clicking the small black arrow.

Next, Select “AppSocket/HP JetDirect”

At the right, new options will be displayed (Host and Port Number)

In the host field, type the IP address of the network printer you’re installing.

In the Port Number field, type the RAW port number for the network printer. If you did not change this directly in the Printer’s Settings, or you are not sure, then leave the default value 9100.

Select Device

Press the “Forward” button: The next panel is the “Choose Driver” panel

Choose the “Select Printer from Database” option

Highlight the “Generic” option under the “Makes” list

Chose Driver Panel 1

Press the “Forward” button: The next panel is the “Choose Driver” panel #2

On this Panel, under the “Model” list, select “PCL 6/PCL XL Driver”

Under the “Drivers” Select the “PCL 6/PCL XL Driver – CUPS + Gutenprint v5.2.3 [en] (recommended)”

Choose Driver Panel 2

Press the “Forward” button: The next panel is “Describe the Printer”

Printer Name: in this field, type a name for your printer as it will appear in you installed printers list. I’ll call mine “Dell1700″ Note that spaces are not permitted here.

Description (optional): In this field, type a short description of your printer to help identfy it in you installed printers list. I described mine as “Dell Printer Home Office”. You can leave this blank if you want.

Location (optional): In this field, put a location descriptor that will help to identify the location of the printer in the installed printers list. For this field, I used “Home Office”. You can leave this blank if you want.

Describe the Printer

When you finish, click the “Apply” button. You’ll be prompted and asked if you want to print a test page, which might be a good idea at this point to make sure you got everything set up correctly.

Test Printing

If everything went well, you will now see a new printer added to your installed printers list under “Printer Configuration“.

New Printer Installed

Note: This walkthrough was completed using a Dell 1700 Laserprinter and does work with these instructions. This printer does not have linux drivers available. If your printer has supported/avalible drivers provided by your manufacturer, your setup process may be different. This information is provided as a general guide.

I hope you find this information helpful. Leave a comment to let me know what you think. Is there a better / easier way to do this? Did I miss anything? Leave a comment.

I recently set up a WordPress Blog internally for our company to use over our intranet to help improve communication, collaborate, share and develop ideas, and stay informed about company announcements or current events.. etc.

One of the requirements I had was to allow authentication against our Active Directory. Yes, we operate a Windows network primarily, but you can also authenticate against other LDAP directories as well. This was important from an IT position as well as the participants of the blog. I felt people would be more likely to participate if they didn’t have to manage separate user accounts for each service on the intranet. I also set up a Wiki that is Active Directory enabled. I’ll post about that at a later time. The point is, it makes little sense to create different credentials for each user with each new service. It not only becomes a hassle for IT to track and manage the accounts, it’s also a drag for participants to keep track of and manage their username and password pairs for each service. The result would most likely lead to lack of use and that is not what we want.

Integrating the existing Active Directory accounts means that each participant can access these services using the same credentials they use to access or log into their network accounts and desktops. When time comes to change passwords, you need only to update the Active Directory account and your done. Simple! What could be better?

Starting Point

The first thing we needed to do was find out how to include AD Authentication with WordPress 2.5. There are a small number of plugins that claim to allow AD Authentication, but from what I came across, most of them were older and no longer actively maintained. But…there were two in particular that still showed signs of being actively maintained and had promise.

The first was was aptly called “Active Directory Authentication”

The other plugin and the ultimately the one I managed to successfully include is wpDirAuth.

The Trials

Although I was able to get wpDirAuth to work with WordPress 2.5, there was a catch. The current “Official” release of wpDirAuth as of this writing is version 1.2 which is not compatible with WordPress 2.5 so there was some work involved to make this happen. I visited the wpDirAuth plugin page to look at the install directions. They seemed easy enough. It wasn’t until I actually installed and activated the plugin that I realized it wouldn’t work. My next stop was the support channel that the author set up to help troubleshoot install and authentication issues. It was here that I learned there was a patch already available and provided by a generous wpDirAuth user – Adam Yearout. I applied the patch and then tried to login with my network credentials again, and … No luck! By now I was scratching my head. Searching and reading all the information I could find, I finally found myself on the wpDirAuth Developer Support Channel. This was another channel set up specifically for developers. It was here that I uncovered some clues as to what was happening and a small code tweak that was necessary to overcome the problem. Apparently, the author of the plugin assumed that the login name was also the name associated with the Active Directory Account Email, which in most cases is true, but not always. For example username: johndoe would by default have an email johndoe@domain.com. In my case, my email and name and login name were not the same, so the logic that the plugin author used would not work. The good news is that the fix is a fairly simple one if you know where to look and the dev channel contained all the clues needed to find the info.

Setting up wpDirAuth with WordPress 2.5

For this how-to, I am using wordpress 2.5 installed on an Ubuntu 8.04 LTS server With Apache2 and PHP5. There is no GUI and I am not running an ftp server on this server so all settings and changes are completed using putty over SSL.

So lets get to it. Setting up AD Authentication was not as straight forward as I had hoped and required a few extra steps along the way.

The first step is to download the wpDirAuth plugin from the WordPress plugins section.

From a terminal or if logged into the server via Putty, change to your home directory and get the latest version of the wpDirAuth plugin.

Next extract the files by executing:

Now you have a new directory called wpdirauth.1.2 in your home directory.
Move into the new directory and list the contents using

Now you will see the wpdirauth directory. You need to move this entire directory to your WordPress plugins directory.

To move the extracted wpdirauth directory, make sure you are in the wpdirauth.1.2 directory and execute the command:

Now we need to move into the actual WordPress Blog directory where our files are hosted by executing the command:

Now if you execute

you should see the wpdirauth plugin folder. Once again, we will change directories and move into the hosted wpdirauth directory using:

This is where the editing (and the fun) begins.
Remember, we need to make some changes before we activate this plugin in WordPress 2.5 or it will not work.

Patching the wpdirauth plugin

Before making any changes to our files, it’s alway a good idea to make some backups.

From the wpdirauth execute the command:

Next apply the patch that was just downloaded. This patch will make changes to the wpdirauth.php file, and update the Plug-in version for 1.2 to 1.3

Apply the patch by executing the command:

Editing the plugin

Once the patch is installed, your Active Directory authentication should for most people. But we are not done yet.

There is an issue related to Active Directory users names and their email addresses. Active Directory user accounts that are also created with an email address, are by default given an address equal to the login name.
For example an Active Directory user created with a login name of johndoe would have an email address of johndoe@domain.com. The problem arises in the way that wpDirAuth authenticates against Active Directory using the email address. If at some point, the users default email address is changed, the login name does not match the email address and authentication fails. The fix is a simple one if you know where to look.

To prevent authentication failure due to the login name and email mismatch, you need to make a small edit to the wpdirauth.php file. Start by executing the following command:

Next, scroll through the file till you find the wpDirAuth_auth() function at line 246. It should be about 1/4 of the way down the page. Edit this function as follows:

At about line 273 find the line

and delete or comment it out.

Next move down to about line 284 and look for the line that reads:

Add a new line after this and enter the following:

Basicly, we are just moving the line “if ($accountSuffix) $username .= $accountSuffix;” down a few lines and adding it after the line ” $filterQuery = “($filter=$username)”; ”

This is the snippet of the the wpDirAuth_auth() function after I made the changes look like this.

Activating the Plugin

One requirement that may still be missing is php’s LDAP support. If you do not already have support for LDAP enabled in php, you will need to enable it before you can authenticate against the Active Directory.
To enable LDAP in PHP, execute the following command

At this point, and assuming everything went well, it’s time to log into your WordPress Blog as the WordPress Admin and navigate to the “settings” page. From here, you will see a “Directory Auth” link at the top of your settings page. click this link to access the Directory Auth setup page and fill in the required fields as they apply to your Active Directory set up.

Enable Directory Authentication = yes
Require SSL Login = Yes if you use SSL Auth, No if you do not.
Enable SSL Connectivity = yes if you are using SSL or LDAPS connections, No if you are not.
Directory Servers (Domain Controllers) = DNS Name or IP Address of your Active Directory Domain Controller
Account Filter = samAccountName or field to search the username to locate the directory profile. For AD, samAccountName should work.
Account Suffix = @yourdomain.com – This is the suffix for you local domain usen in email addressing in the AD for you local network.
Base DN = DC=domainname,DC=com – Note this will vary depending on you local network and complexity of your AD
Bind DN = Blank if you allow Anonymous Binding to your Directory or a username use to pre-bind if you do not.
Bind Password = Blank if you allow Anonymous Binding to your Directory or the password of the user used to pre-bind if you do not.

The remainder of the fields are self explanatory and are not critical to successful authentication.

Now save the changes and log out of the WordPress Admin account.
Next attempt to login to WordPress using an Active Directory User Account.

You should now have Active Directory Authentication enabled and working with WordPress.

Remember, your mileage may vary depending on your specific needs and existing network and Active Directory structure.

Have any other tips, or want to share your experience with AD authentication in WordPress? Leave a comment.

One thing to note is that these commands need to be issued from either root or using sudo. I prefer to use the sudo su method to avoid having to type sudo each time I issue a command. (WARNING) if you do use sudo su, remember to exit the root when you are done.

In this example, I will be assigning the a static IP address of 192.168.1.2 to the primary network interface on my server.
My network subnet is 192.168.1.0
My network gateway is 192.168.1.3
And my netmask is 255.255.255.0

1. Gain root privledges

sudo su

Enter your password when prompted You should now have root access.

2. Backup your interfaces file

cp /etc/network/interfaces /etc/network/interfaces.backup

It is important to always create a backup of important files in case you need to restore your original files/settings.

3. Edit the Interfaces file
Now using a text editor, modify the /etc/network/interfaces file. I prefer to use nano, but you can use any editor you prefer. For this example, I am going to use 192.168.1.2 as my static ip address.

The original the interfaces file looks like this:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet dhcp

To set a static IP, you need to change the line under “The primary network interface” to something like this.

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.3

5. Confirm Your Changes
Your edited interfaces file should now look something like this.
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).
# The loopback network interface
auto lo
iface lo inet loopback
# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
network 192.168.1.0
broadcast 192.168.1.255
gateway 192.168.1.3

6. Save Your Changes and Restart Networking

If your changes are correct, you now need to save them to the interfaces file. If you used Nano, to save the new file, you press Ctrl-o to write the changes (hit enter when asked to overwrite the existing file) and the Ctrl-x to quit nano.

Once your changes are saved you need to restart the networking service on the server by issuing the following command.

/etc/init.d/networking restart

7. Test and Confirm
If everything went well, you now have a static IP assigned to the eth0 network interface.
To test and make sure your changes were applied successfully, issue this command:

ifconfig eth0

Your output should look something like this:

eth0 Link encap:Ethernet HWaddr 00:02:E3:09:C2:FB
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::202:e3ff:fe09:c2fb/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:512598 errors:0 dropped:0 overruns:0 frame:0
TX packets:5428 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:30923166 (29.4 MB) TX bytes:547585 (534.7 KB)
Interrupt:10 Base address:0x6000

Note the second line
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
now shows the correct static ip, Bcast and Mask information that we assigned.

If you gained root by using the sudo su option, remember to exit root by simply issuing the “exit” command.

I thought to myself, If the 2.0 Framework is installed, why won’t it just use that. So I open up the Internet Services Manager for IIS to see if there was anything there that could help me figure this little issue out. Well, as it turns out, you need to specify what framework a web uses to execute it’s code from within the IIS Manager console. These settings are found by right clicking on the target web site in the Manager console and selecting “properties”.

Now in the properties panel, select the ASP.Net tab. In this tab view you should see a form page containing a few fields and a couple buttons. The first field at the top of the form is labeled “ASP.Net Version” and has a drop down menu containing the available installed framework versions. Select the appropriate version you want to use to process asp.net pages for the web your working in and hit the “Apply” or “OK” button. That’s all there is to it! You can also specify different Frameworks for different webs that are hosted on the same server. One of the good things about the .Net Frameworks is that they install and run independently of each other.

This is a topic I revisit often and a lot of good points are brought up in this article.

This will be helpful if I decide to stick with Exchange and upgrade to the 2007 release.

It is time to start planning for server upgrades at the company I work for. At the center of our network, we have an exchange 2000 server loaded with public folders. Public folders are crucial to our daily work and are used to organize all current publicity tours.

Unfortunately, Microsoft has planned to discontinue support of public folders after the Exchange 2007 release. From what I understand, they are available in the new release (2007), but not by default and will not be available in future releases. The system requirements also up the ante for an exchange upgrade, and our current hardware will need to be upgraded as well…which brings me to my dilemma.

I am leaning toward a recommendation for upgrading to Exchange 2007 and migrating to new server hardware required as well, …OR… do I consider the alternatives?

1) I have done some research on Exchange replacements and it seems that Scalix or Zimbra are as close as they come and they actually look pretty impressive. These run on linux based platforms and would run on existing hardware with public folder support. But this doesn’t come without it’s potential pitfalls.

The transition from Windows 2000 – Active Directory – Exchange combo to a Linux – LDAP – Scalix/Zimbra is not exactly an easy way out.

How does LDAP compare to AD for use with user/group authentication?
Can user and group accounts be transfered from AD to LDAP and maintain network permissions?
Can users be managed in the same way using LDAP as they are in AD?
Can I use Scalix/Zimbra with AD and forget the idea of needing LDAP? (after all, AD is pretty much just a modified LDAP).

2) Do I recommend the Exchange upgrade and try to find public folder replacement or develop a custom in-house replacement.

I like the idea of breaking the windows licensing trap and the potential savings, but at the same time, I am cautious about the support available with the alternatives, not to mention changes required make such a transition. I tend to think that the the second option is likely the easiest and more hassle-free of the two, however, I have yet to come across anything that works like public folders in a stand alone application.