Setting up FreeNAS in a VM

As I mentioned above, my main preference is to run FreeNAS in a VM. However, you can of course install it on a physical PC/Server or even run it in embedded mode using a USB flash drive. I will be downloading the 0.7.2 build in VMware Image format and setting this up.

Open the .VMX file for the VMware image in VMware Workstation or Server. Add an extra Hard disk to the VM choosing a SCSI disk with the desired size you would like to use for your Data Shares. I added a 120GB drive as I wanted to have 120GB for my ESXi hosts to use to run Virtual Machines from.

If you choose to go your own installation route, or would like to install FreeNAS on a physical machine, the installer is really simple to use, consisting of just a couple of options that ask which disk you would like to install it on and whether you want a swap partition or not.

Continuing with the VM setup, let us get started by powering on the FreeNAS server image. You will be asked if it has been moved or copied. Choose “I copied it”. Once it has booted you’ll be up and running with the fully installed version of FreeNAS and have some options to work with as seen below.

Configure your Network interface by choosing option 2) and entering your local network information. Turn DHCP off as you’ll want a static IP address for this server. You’ll set up an interface name, IP address and subnet mask, default gateway and DNS.

Now you can browse to the IP address you configured using the format http://IPAddress in your local machine’s web browser. Your default credentials are admin/freenas to login with. You’ll see the main configuration page which should look similar to this:

Provisioning a NFS Share

First things first, we’ll get our data disk configured for use. Go to Disks -> Management and click the little “+” (Plus) sign on the far right to add a disk. You should see your data disk (da1) in the dropdown menu. Just ensure you have your added disk selected in this dropdown. Type in a short description and leave all the other options at their defaults. Click the “Add” button to add the disk, following which you’ll see the disk set to “Initializing”. Click the “Apply changes” button to confirm changes.  You should now see your disk as ONLINE.

We need to format this disk, so open up Disks -> Format, choose “da1” (your extra data disk) and select UFS for the file system. Assign a volume label and leave all other options at their defaults. Proceed with the format. Here is a rundown of the settings I used:

Go to the Disks -> Mount Point section next, then click the “+” (Plus) sign to add a mount point. Configure it as per the screenshot below (with the exception of assigning your own mount point name) then click “Add” at the bottom when done.

Make sure you “Apply Changes” when the disk mount point has been added. Your Mount Point status should now show as OK.

Next up, navigate to Services -> NFS. Click the “Enable” tick box for “Network File System” then click the “Save and Restart” button to enable the NFS service for your server. Now click the “Shares” tab under the NFS section and configure a share by clicking the “+” (Plus) button on the right.

Configure your NFS share using the screenshot below as a guide – your path should be something like /mnt/YourMountPointName – this is the path that your client machines will connect to  (VMware ESXi hosts for example). In my configuration case, the Path is: /mnt/Datastore120GB. Select the authorized network range (the client network that will be allowed access to this share) and tick the option for “Share all sub directories”. Be sure to click the “Add” button at the bottom when finished, and apply the changes on the page that follows.

Conclusion

Now that the share is setup it should be simple enough for your clients (or in my case ESXi hosts) to connect to. Here is how I connected my ESXi hosts to this share so that they could use a centralized storage location to run multiple VMs from. Having this shared storage allows them, whilst being connected to vCenter Server, to use features such as HA (High Availability) and DRS (Distributed Resource Scheduling – as all hosts need to have access to the exact same storage as a requirement).

1. Connect to ESX/ESXi host using vSphere client
2. Go to configuration tab
3. Click on Storage -> Add Storage
4. Select “Network File System”
5. Enter the FreeNAS IP address as the Server
6. Enter the “Folder” as the share name.

Finish the wizard.

You can of course use your FreeNAS server to host other shares too. As mentioned in the beginning, you can use other protocols such as CIFS, FTP, iSCSI (another great protocol for VMware hosts needing shared storage), and many others with FreeNAS. Network Attached Storage is a great way to provide shares to more than one client machine and in my case makes for an excellent lab storage virtual appliance.

In part one of this series, we looked at how to identify the relevant machines on your network (i.e. machines which are currently offering refuge to PST files), and in part 2 we covered how to use the Exchange Management Shell to identify the filenames, owners and locations of the PST files those machines. This final video will complete the process, and cover the actual import procedure.

In the previous video I identified the machine names of the computers on my network for use in a subsequent search for PST files. In the next video I will look at the scripts that will setup the Import-Mailbox requests from these PSTs into the relevant mailboxes in Exchange.

In the next video I will go through finding PST files on your network.

The following script does just that:

# Read in pst file locations and users
$strPSTFiles = Get-Content -Path "c:\pstdetails.csv"
foreach($strPSTFile in $strPSTFiles)
{
$strMachine = $strPSTFile.Split(',')[0]
$strPath = $strPSTFile.Split(',')[1]
$strOwner = $strPSTFile.Split(',')[2]

# Get network path for pst file
$source = "\\" + $strMachine + "\" + $strPath.Replace(':','$')

# import pst to mail box.
Import-Mailbox -PSTFolderPath $source -Identity $strOwner
New-MailboxImportRequest -FilePath $source -Mailbox $strOwner
}

The yellow highlighted text shows the Exchange 2010 RTM cmdlet, the red the Exchange 2010 SP1. Delete the unneeded version as appropriate.

The Exchange 2010 SP1 version of the script will execute in far less time, due to the asynchronous nature of the ImportRequest cmdlet. These requests are processed in the background and can be monitored with the Get-MailboxImportRequest cmdlet to observe their status.

There are quite a few potential pitfalls here:

1. The user’s machine must be on.
2. File sharing must be on, to allow for the file to be transferred.
3. Outlook must not be running on the remote user’s machine. If Outlook is running and has the PST file attached, the file will be locked and unable to be imported.
4. The PowerShell cmdlet used by Exchange to import PST files does not support passwords.

There are various things you could to augment this script.Some suggestions include:

•  Have WMI shut down Outlook on a remote user’s machine before attempting import http://www.computerperformance.co.uk/vbscript/wmi_process.htm
• It could be useful to generate a further file detailing a list of all the PSTs which failed to import, with the reason. These files could have been password protected, or the machine hosting them may have been shut down, or become disconnected since they were identified.

I hope you have found this series of articles on manually importing PST files into Exchange 2010 useful. Although, like me, I’m sure you feel that this is a bit of a mammoth task, particularly for the Powershell novice!

To automatically import PST files into Exchange 2010 without Powershell visit:
www.red-gate.com/products/pst_importer_2010. Here you can find out more information on PST Importer 2010 and download a free 14 day trial.

To start this, we  can query Active Directory for a list of all the machines attached to your domain. We can then use Windows Management Instrumentation (WMI) to search each of these machines for PST files. The file paths for these PSTs should hopefully give a clue as to which user they belong to, as they will be created in a directory path containing the username by default. We can also grab the file owner file attribute which should correlate with the file path.

This technique requires that all the machines in your network are switched on and accessible by WMI. A list of the machines which could not be queried can be provided as output

Notes about WMI:

By default WMI is blocked by the windows firewall in Windows 7 and 2008 R2. You’ll need to open up the ports on all your users’ machines. This can be done with the ‘netsh’ command, or through a change to group policy.

What are the implications of this? WMI is a powerful beast, and allows remote access to many aspects of a user’s machine. As such it could be considered a security vulnerability… It’s typically accessed though port 135. This not only permits access to WMI – but also any other DCOM components which may be installed on a machine, open for exploitation by Trojans and the like. Needless to say, the ports are blocked by default for a reason – so require careful consideration of the implications when opening. WMI will also not help you if the machines you wish to tinker with are subject to NAT (Network Address Translation). You’ll be unable to reach these machines. The following script generates a txt file (the filename defined on line 2) of all the computers on your domain to be searched. This can then be edited with notepad to remove those you don’t wish to search.

$strCategory = "computer"
$strOutput = "c:\computernames.txt"
$objDomain = New-Object System.DirectoryServices.DirectoryEntry

$objSearcher = New-Object System.DirectoryServices.DirectorySearcher
$objSearcher.SearchRoot = $objDomain
$objSearcher.Filter = ("(objectCategory=$strCategory)")

$colProplist = "name"
foreach ($i in $colPropList){$objSearcher.PropertiesToLoad.Add($i)}

$colResults = $objSearcher.FindAll()
[bool]$firstOutput = $true
foreach ($objResult in $colResults)
{
$objComputer = $objResult.Properties;
if($firstOutput)
{
Write-output $objComputer.name | Out-File -filepath $strOutput
$firstOutput = $false;
}
else
{
Write-output $objComputer.name | Out-File -filepath $strOutput `
-append
}
}

The next script will generate a CSV (Comma separated values) detailing the network paths of the PSTS you need.

$strComputers = Get-Content -Path "c:\computernames.txt"
[bool]$firstOutput = $true
foreach($strComputer in $strComputers)
{
$colFiles = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query "Select * from CIM_DataFile `
Where Extension = 'pst'"
foreach ($objFile in $colFiles)
{
if($objFile.FileName -ne $null)
{
$filepath = $objFile.Drive + $objFile.Path + $objFile.FileName + "." `
+ $objFile.Extension;
$query = "ASSOCIATORS OF {Win32_LogicalFileSecuritySetting='" `
+ $filepath `
+ "'} WHERE AssocClass=Win32_LogicalFileOwner ResultRole=Owner"
$colOwners = Get-Wmiobject -namespace "root\CIMV2" `
-computername $strComputer `
-Query $query
$objOwner = $colOwners[0]
$user = $objOwner.ReferencedDomainName + "\" + $objOwner.AccountName
$output = $strComputer + "," + $filepath + "," + $user
if($firstOutput)
{
Write-output $output | Out-File -filepath c:\pstdetails.csv
$firstOutput = $false
}
else
{
Write-output $output | Out-File -filepath c:\pstdetails.csv -append
}
}
}
}

This script will take as input a text file containing a list of machine names (conveniently the output of the first script), and will generate a csv file of all the pst files found on those machines, and the owners associated with them.

Find PST files across your network quickly and easily with PST Importer 2010. To find out more and to download a free 14 day trial please visit:
www.red-gate.com/products/pst_importer_2010

Error:
Error was found for (username) because: Error occurred in the step: Approving object. An unknown error
has occurred., error code: -2147221219
+ CategoryInfo          : InvalidOperation: (0:Int32) [Import-Mailbox], RecipientTaskException
+ FullyQualifiedErrorId : CFFD629B,Microsoft.Exchange.Management.RecipientTasks.ImportMailbox

Here is how I worked round it.

After doing some digging,  I found the site http://www.korneel.nl/?p=28 that  identifies most of the problems you might hit importing a PST file.

The cause for the error in my case transpired to be an acknowledged (according to the blog post) bug in exchange, presumably with an upcoming hotfix. However, it seems to be a generic error for all ills, as other solutions on the web suggest using the ‘fixmapi’ command (though admittedly referring to exchange 2007…). http://social.technet.microsoft.com/Forums/en-US/exchangesvrmigration/thread/82424f36-2611-4188-808e-df9aad36a5b7 (And the most common suggestion being adding the import export role to the user account.)

Another potential pitfall is the requirement for the 64bit version of outlook 2010 to be installed. It’s worth noting that by default an installation of Office 2010 on a clean machine will install the 32bit version.

As an unrelated aside,  installing the SP1 beta on exchange also caused a few problems – it required the manual installation of several hot fixes – and more annoyingly one package (UCMA 2.0 Runtime 64bit)– which despite coming as an ‘msi’ installation package, and on running giving all the signs it had installed successfully – had actually only ‘installed’ the installation files, which then had to be run separately. I’m sure these niggles will be ironed out before SP1 is released, but it wasn’t the friendliest of upgrades.

PST Importer 2010 provides a simple and transparent way to find and import PST files into Exchange 2010. To find out more information and to download a free 14 day trial please visit: www.red-gate.com/products/pst_importer_2010

To start with you will obviously require more than one Domain Controller in your Windows domain. In my case I have a “Primary” and “Secondary” domain controller called “NOOBS-DC1″ and “NOOBS-DC2″.

Transferring roles

RID, PDC or Infrastructure roles:

Start by opening Active Directory Users and Computers on the DC you want to change the role to. Right-click your domain name and select “Operation Masters” from the context menu.

Select the tab corresponding to the role you would like to transfer. Below this you should be able to see the name of the DC you are currently on, or connected to. Click the “Change” button to change the role over to the DC listed.

Confirm the change when asked, at which point you should receive a message stating that the procedure was successful.

Remember that this method can be used to transfer any of the RID (Relative ID), PDC (PDC Emulator) or Infrastructure roles. Just select the role you want to transfer by using the relevant tab.

Domain Naming Master role

Again, start on the DC that you would like to transfer this role to. Open Active Directory Domains and Trusts, then right-click the top level that reads “Active Directory Domains and Trusts” then select “Operations Master” from the context menu.

Check that the DC listed is the machine you would like to change the role to, then click “Change”.

Confirm the change – If all went well you should now receive a message stating the transfer was a success.

Note that you can also use the “Connect to Domain Controller” option in the context menu to connect to the DC you would like to transfer the role to. Access this by right-clicking “Active Directory Domains and Trusts” and then selecting the “Connect to Domain Controller” option. Here is what the Connect to Domain Controller window should look like:

Schema Master role

The Schema master role needs a little bit of extra work to change as the MMC snap-in you use is usually hidden. We will first need to register a .dll file before we are able to access this.

Again, start on the DC you would like the change the role to. Open a command prompt window and type in “regsvr32 schmmgmt.dll” then press Enter. You should receive a message stating the .dll was registered.

Now open a brand new MMC console. (Start -> Run -> type in “mmc” then press Enter). Select “File” then “Add/remove Snap-in” and click the “Add” button. You should see our newly added snap-in called “Active Directory Schema”. Select this option, then click “Add” and then “Close”. Click the “OK” button to go to back to your MMC.

Right-click “Active Directory Schema [your DC name]” and select “Change Domain Controller” if you are not already connected to the DC that you would like to inherit the role. Specify the DC’s name and confirm. In the screenshots below, I was defaulted to being connected to the DC1 server when loading the snap-in, but wanted to change to DC2 as this was the server that was going to be receiving the “Schema Master” role.

Right-click “Active Directory Schema [your DC name]” and select “Operations Master”. Finally, click the “Change” button to initiate the change. Confirm by click “Yes”, and you should receive a success message.

That should cover the basics of transferring your five FSMO roles between Domain Controllers. In the next part we’ll take a practical look at how to seize roles using the ntdsutil.exe command.

I really do take back what I had said regarding the usefulness of these ancient communications ports back then. I had been pacing through the house trying to find a USB to Serial adaptor, but after an hour or two of searching I came out empty-handed. Suddenly it dawned on me that my old PowerEdge 2450 sitting in my home lab set up had two COM ports. “Why didn’t I think of that earlier?”, I muttered as I hauled my equipment over to the lab to begin setting up. The answer? Well it was running VMware ESX 3.5 and I had absolutely no clue how to display a device’s console via ESX’s service console!

Solution

If for any reason you need to connect to a Cisco device (or any device with a serial cable to connect to the console for that matter) via an ESX 3.5 or 4.0 server then the following should also work for you. I’m also quite confident that this will also work for other Redhat based distibutions of linux.

Start by logging in to your ESX service console as the root user.

You should by default be logged into the root user’s home folder. To ensure you are in the root home folder, you can run the following command:

[root@esx3lab root]# cd ~

Next, we need to download some RPM packages to get the terminal emulation software we are going to be using installed. You could probably download these straight from the service console’s command line, but I prefer to download them to my management machine first then use WinSCP to copy them across to the ESX server. We need two packages, namely: minicom-2.00.0-12 RPM for i386 and lockdev-1.0.0-16 RPM for i386. A google for these two packages turns up many download links, but here are two download links that are currently valid:

lockdev – ftp://ftp.linux.ncsu.edu/pub/realmlinux/realmkit-7.3/i386/RedHat/RPMS/lockdev-1.0.0-16.i386.rpm

Minicom – ftp://fr.rpmfind.net/linux/redhat/9/en/os/i386/RedHat/RPMS/minicom-2.00.0-12.i386.rpm

Once you have these two files we’ll need to copy them over to the ESX server and place them in the root user’s home folder. If you don’t already have WinSCP installed, go grab it from winscp.net now and install it on your Windows management machine.

On the service console of your ESX Host, we’ll need to make a quick change to allow SSH logins from the root user over the network. WinSCP uses an SSH login so this will be necessary if we are going to get anything transferred via WinSCP. Do the following to enable root logins to this ESX Host:

[root@esx3lab root]# nano /etc/ssh/sshd_config

Find the line that reads PermitRootLogin no and change this to read: PermitRootLogin yes

Press Ctrl + X to exit the nano editor and then press Y followed by the Enter key to save changes and exit. You’ll now need to restart the SSH service so do the following command:

root@esx3lab root]# service sshd restart

Back on the management machine with WinSCP installed, launch WinSCP and at the login window, type in the IP address of your ESX server, ensure that port 22 is selected and that you type in the username of root and your ESX server’s root password. Click the Login button, and click “Yes” when asked if you want to accept the private SSH key.

Once you are connected, you’ll be greeted by a file browser interface, with your host machine on the left and your ESX server on the right. The default location will the root user’s home folder on the right, so just select the two RPM packages you downloaded earlier on your host machine, then drag and drop them to the ESX server on the right. Select the “Copy” option when prompted. This will copy the two packages to your root user’s home folder on the ESX Server.

Now, back at the service console (ESX Server) issue the following commands to get the lockdev library and minicom terminal emulator installed:

root@esx3lab root]# rpm --install lockdev-1.0.0-16.i386.rpm

root@esx3lab root]# rpm --install minicom-2.00.0-12.i386.rpm

Note that seeing as though you now have root SSH access to the ESX server, you could also just login to the Service Console using PuTTy – use the same details to login as we did with WinSCP. This will save you the hassle of having to sit in front of the ESX server itself, or connecting via a Remote Access Card.

We’ll now identify the serial port interfaces that our physical ESX server has. Run the following command:

root@esx3lab root]# dmesg |grep tty

You should get an output similar to the image below:

ttyS0 refers to the COM1 port and ttyS1 refers to the COM2 port on the server I am working on. Note the values that you get down. We’ll be using these to set up minicom next.
To start configuring minicom (provided it installed in the previous step!) issue the following command on your ESX host:

root@esx3lab root]# minicom -s

Go to Serial port setup in the menu, press Enter, then press A to configure the Serial Device as illustrated in the screenshot below. Type in /dev/ttyS0 if you are going to be using COM1 to connect the serial cable to your Cisco / network device. Note that ttyS0 assumes that this is the device you found when you ran the “dmesg |grep tty” command previously. In my case I found ttyS0 and ttyS1 for COM1 and COM2. Press Enter to accept the entry. Now configure the “Bps/Par/Bits” setting. Press “E” to adjust this and ensure it reads 9600 8N1 – you should actually match this to the baud rate needed by the device you are connecting to. I used the above line as this is the standard for most default Cisco equipment. Press Enter to accept, then Enter again to go back to the main menu.

Next up, go to “Modem and dialing“. You’ll notice some strings entered in the “Init string” and “Reset string” lines. Erase these so that they are blank, then hit Enter to accept the setting and return to the main menu.

Now choose “Save setup as dfl” and then select “Exit from Minicom” to exit back to the ESX console.

Now, for the grand finale. Connect your serial console cable to the ESX server’s relevant COM port, then plug the other end into your Cisco or other network device that you want to configure. Type in the following from the ESX Service Console to connect:

root@esx3lab root]# minicom

You should be greeted by the Minicom welcome screen. Hit Enter and you should now see the console of your device you are plugged into!

Here are a few commands for minicom to get you started:

CTRL + A, then Q – Quit minicom and return to server console.

CTRL + A, then F – Send a “Break” to your connected device. (Quite useful for Cisco equipment).

CTRL + A, then Z – Show the minicom help screen, which displays other useful commands.

Conclusion

You should now have an ESX host that is able to interface with your equipment via a console cable. This how-to doesn’t necessarily only apply to ESX servers – you should be able to use it for just about any linux-based machine you have at your disposal. Hopefully, like it did with me, this process will save your sanity one day when you find you are without the means to connect to a device console over serial cable!

This week we did a test activation of the SCR replica in our test environment, but ran into an issue that we could not find a documented solution for.  In the hope that it saves someone else some time and anguish I’ve written about it here.

The procedure for activating an SCR copy is pretty well documented on Microsoft TechNet.

Step four in the activation procedure is to run the Exchange 2007 command line setup program, setup.com, to configure the clustered mailbox server on the SCR server.  The command line looks like this:

Setup.com /RecoverCMS /CMSName:<CMS Name> /CMSIPAddress:<IPAddress>

When we ran the command on our SCR server we received this error output:

Clustered Mailbox Server         ……………………. FAILED

Deleting virtual directory ‘IIS://exchangecms.example.com/W3SVC/1/ROOT/Exchange’ on ‘exchangecms’ failed.

The virtual directory ‘Exchange’ already exists under ‘exchangecms.example.com/Default Web Site’.

Parameter name: VirtualDirectoryName

The Exchange Server Setup operation did not complete. For more information, visit http://support.microsoft.com and enter the Error ID.

Exchange Server setup encountered an error.

An event 1002 error was also logged in the Application event log:

Exchange Server component Clustered Mailbox Server failed.

Error: Error:

Deleting virtual directory ‘IIS://exchangecms.example.com/W3SVC/1/ROOT/Exchange’ on ‘exchangecms’ failed.

WMI exception occured on server ‘exchangecms.example.com’: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Error:

The virtual directory ‘Exchange’ already exists under ‘exchangecms.example.com/Default Web Site’.

Parameter name: VirtualDirectoryName

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

There is a similar issue described in this Microsoft Knowledge Base article: http://support.microsoft.com/kb/971713, but that did not help us as the conditions of our situation were different – both our SCR and CCR test servers are in the same AD site.  Nevertheless we checked our DCs and replication and found no problems.

After first checking the obvious things – domain controller replication, DNS and WINS name registrations and resolution, and re-running the command several times, we realised that the SCR server had managed to partially bring up the clustered mailbox server.  The Exchange services had been added to the cluster group, including the cluster name and IP address.  This meant that the server which setup was trying to modify must have been the SCR server itself.  We started IIS manager on the SCR server, and sure enough, the ‘Exchange’ virtual directory did indeed exist under the ‘Default Web Site’.

We removed the three Exchange virtual directories, Exadmin, Exchange, and Public, and re-ran the setup.com command and the process went through without any further errors.

So, if you are trying to activate an SCR replica, and you get an error telling you that the Exchange virtual directories already exist, try removing them on the SCR server.