Remote Server Admin Tools and Exchange Management Tools for Windows 7

The instructions for this were taken from this link:

With the introduction and testing of the newest Windows OS from Microsoft, system administrators are actively seeking ways to remotely manage their servers and networks.  In order for this to take place administrators have to resort to several different tools, such as a second workstation running Windows XP or Windows Vista, or Virtual Workstations on their Windows 7 RC computer.  I am working with the Microsoft Development department to get this listed as an approved management method for ESM.  However I am still waiting for them to determine if they even want to support Windows 7 and Exchange / Server 2003.
In August of 2008, Microsoft released Exchange Manger for Windows Vista, and it worked out great for the IT community.  This was released as ESMVista.msi pack from Microsoft.  The good news for everyone, these tools actually do work on Windows 7 RC in an Exchange 2003 environment.  However there is a slight Catch.  You ask what that catch might be, you cannot install ESMVISTA.msi on a Windows 7 machine.  The issue is that the MSI for Vista has a few system checks it performs to ensure you are not installing it on a Windows XP, 2003, or 2000 machine, and it will give you this lovely little message stating something like “Windows Vista is required.”

The answer to this issue is to ensure the MSI file does not attempt to check your system to see what version of windows is currently running on your computer.  I have taken the liberty of removing these checks and renaming the MSI file for use with Windows 7 Click Here.  If you would like to make the changes yourself you will need to download the ESMVISTA.msi from Microsoft, Click Here and modify it yourself.  Another option that I have not tested is to run the ESMVista.msi from the command prompt with the following command… This will keep you from having to edit the MSI file.  Again I have not tested this procedure.

1: msiexec /i esmvista /q

Before you can just install this MSI file there are some other prerequisites you must perform first.
1.  You will need to make sure that Microsoft Outlook is not installed on the workstation you are performing this task on, if the application is already installed you will need to temporarily remove the program.  Removing Outlook will not delete your profile.
2.  You will need to install the Windows 7RC update for Remote Server Administration tools.  You can access this file byclicking here to access the Microsoft site.
3.  Open Control Panel and select Programs and Features.
4.  Select the Turn Windows features on or off.
5.  Expand Remoter Server Administration Tools and all child items.  Check each of these items and click OK.
6.  You will need to install the ExchangeMapiCDO.msi file from the Microsoft site by clicking here.  This update will fail to load if MS Outlook is installed on the workstation.
7.  You will need to install the ESMWindows7.msi file that can be downloaded by clicking here. You can get the ESMVISTA.msi file by clicking here.
8.  Open ADUC, and select the view menu to enable advanced features.
9.  Reboot the computer, and re-install Outlook if needed.

In summary, Windows 7 RC will work with the same Exchange Server Management Tools as Windows Vista, you just need to get past the System Checks in the MSI files.  I have tested this process in a Server 2003 Domain network that is running Exchange Server 2003.  All the Exchange tabs, and task are present and operate correctly. The installation of the Exchange tools on Windows 7 is actually fairly easy and should allow you manage your network effectively without the need to copy and register those pesky .dll files.

Hope this article will assist you with your daily task.  Just keep in mind this is not approved or supported by Microsoft yet.  Hopefully it will be soon.

Getting ADUC to see the Exchange 2003 Attributes on Windows Vista…

I found a post similar to this which had similar steps and tried it on my Vista computer and it worked well.  Trying on my Windows 7 computer I get an error when I run the regsvr32 command.  Not sure how to resolve this for Windows 7. May look into this in the future when I need it.  Steps from the link above are copied below

Hiya Folks, most of us know that the Exchange Management Extensions for Exchange 2003 are not supported – or do not work on Windows Vista, however – there is a way that you can get the Active Directory Users and Computers Snap-in to work with Windows Vista which will allow you to manage Exchange attributes.

In this post I would like to take you through getting ADUC with the Exchange extensions to work under Windows Vista.

Firstly in order for this to work you will need;

  • A download of the Windows 2003 SP1 Adminpak.msi file, which can be obtained from:
  • Your Windows Vista computer to be a member of the domain that contains the Exchange Server that you wish to manage using ADUC
  • Be logged onto the Vista machine with an account that has permissions to administer the local machine and the domain (or modify accounts in AD)
  • You will need the following files from your Exchange Server (these may be located in theWindows\system32 folder or in the program files\exchsrvr\bin folder);
    • exchmem.dll
    • glblname.dll
    • Address.dll
    • maildsmx.dll
    • netui0.dll
    • netui1.dll
    • netui2.dll
    • pttrace.dll

Addtionally I would suggest that you copy over the “Active Directory Users and Computers.msc” file from the c:\program files\exchsrvr\bin directory on your Exchange server to a location on your machine (this will ensure that you have the latest version of the msc)

Follow the guidance from for installing the Adminpak.msi on Vista from Daniel Petri’s site, which is located here:

Copy all of the DLL’s mentioned above to the c:\windows\system32 folder then run the following command line regsvr32 c:\windows\system32\maildsmx.dll

You should now be able to open up the ADUC and manage users accounts as you normally would from you Windows Vista Session.

Leopard diskutil Software RAID

Here is a helpful link:

I recently had a degraded software RAID on one of my Leopard servers.  In trying to rebuild the disk through Disk Utility, I was getting a unrecognized file system error.  I found this post:

I followed the following steps:

#Checked the RAID status
root# diskutil checkRAID
Name: Server_HD
Unique ID: 7E31E20E-F53D-4D76-AD37-139C4E1440AB
Type: Mirror
Status: Degraded
Size: 1000070610944 B
Device Node: disk2
Apple RAID Version: 2
Device Node UUID Status
0 disk1s3 BAC72F86-B05F-4B0F-97D3-58A6207E7DFA Failed
1 disk0s3 2BFB55BB-EFF9-438C-A1F9-A8ED7A93D385 Online
#Told it to resync
root# diskutil repairMirror disk2 disk1s3
Note: Syncing data between mirror partitions can take a very long time.
Note: The mirror should now be repairing itself. You can check its status using ‘diskutil listRAID’.
temp:~ root# diskutil listRAID
Name: Server_HD
Unique ID: 7E31E20E-F53D-4D76-AD37-139C4E1440AB
Type: Mirror
Status: Degraded
Size: 1000070610944 B
Device Node: disk2
Apple RAID Version: 2
Device Node UUID Status
0 disk1s3 9D955C85-7EC0-4E92-848A-62D9F7C12EED 0% (Rebuilding)
1 disk0s3 2BFB55BB-EFF9-438C-A1F9-A8ED7A93D385 Online

When I ran the diskutil listRAID command, there was still a failed message on the disk. I had recently installed SmartReporter and thought that might be causing an issue.  I had installed it on two other servers with no issues. So I stopped SmartReporter and the repairMirror command worked and the RAID started rebuilding.

I found this second post to use the diskutil checkRAID, diskutil addToRAID and diskutil removeFromRAID commands to rebuild the RAID as well.

Backup Open Directory Script

I recently needed to backup our OD server to make sure in case of a disaster we could recover the accounts used to access our separate web server.  I found in Apple’s Open Directory Administration Manual steps you need to take to backup the OD files and databases.  Below is my backup shell script.


# From Apple OD Administration Manual

# To back up an Open Directory master, you need to backup

# its shared LDAP directory domain, its configuration files,

# and its Open Directory Password Server database.

# Check for root privs

if [ $(whoami) != “root” ]


echo “You need to be root to do this.”

exit 0;


#Set some variables

SLAPCAT=$(which slapcat)

CP=$(which cp)

MKPASSDB=$(which mkpassdb)

# Save the complete contents of the LDAP directory

# as a raw LDIF dump in a text file named backup.ldif

# The file contains all user records, group records,

# computer records and so on. It does NOT contain passwords.

$SLAPCAT -l /Path/to/backups/backup.ldif

# Make a copy of the /etc/openldap folder. This folder

# contains files that determine the setup of the LDAP directory

# domain, including schema files.

$CP -rp /etc/openldap/ /Path/to/backups/

# If your LDAP server uses SSL, make a copy of the server

# certificate file, LDAP server’s private key file, and the CA

# certificate file.

#$CP file_location file_destination

# Make a copy of the OD Password backup folder, located at





# DIRECTORY DOMAIN. Keep the backup media as secure as the

# OD master server.

$MKPASSDB -backupdb /Path/to/backups/mkpassdb/

# Optionally, make a copy of the Library/Preferences/Directory/Service folder

# Files in this folder specify the server’s search policies and specify

# how the server access other directory domains.

# Optionally make a copy of /etc/hostconfig file

Shibboleth Apache Multiple Virtual Host configuration for Moodle


Below are steps to configure a shibboleth SP to work with multiple Apache virtual hosts using a single entityID and an Assertion Consumer Service (ACS) and shibboleth’s NativeSPApplicationOverride. More information can be found here regarding NativeSPApplicationOverride

You will need to do this if you are running more than one virtual named host and each virtual host is running it’s own Moodle instance.

In this example, we will use the server names and with an entityID of

Note: You will need shibboleth installed and 2 instances of Moodle installed. You will also have needed to request attribute releases for the entityID and the ACS where is the entityID and is the ACS that is associated with the entityID.

shibboleth2.xml file configuration

Below are the changes I needed to make in the default configuration file. All other settings were left as default from the shibboleth 2.1 installation.

Modifying the host name for the 2 virtual host web servers

<RequestMapper type="Native"><RequestMap applicationId="default">

<Host name="" ><Path name="default" authType="shibboleth" requireSession="true"/></Host>

<Host name="" applicationId="moodle2" authType="shibboleth" requireSession="true"/>


Entering entityID

<ApplicationDefaults id="default" policyId="default"entityID=""REMOTE_USER="Shib-eduPersonPrincipalName"signing="false" encryption="false">

Point to Production UCLA IdP

<SessionInitiator type="Chaining" Location="/Login" isDefault="true" id="default"relayState="cookie" entityID="">

Pulling the MetadataProvider ID Information

<MetadataProvider id="incommon" type="XML"xmlns="urn:mace:shibboleth:2.0:metadata"url=""backingFilePath="/etc/shibboleth/InCommon-metadata.xml"reloadInterval="28800"></MetadataProvider>

Setup the ApplicationOverride

<ApplicationOverride id="moodle2" entityID=""/&gt;

Save and close the file. Check the shibboleth configuration file for errors: shibd -t and restart the shibboleth service: service shibd restart

Apache Virtual Host Configuration

Note: The Moodle root for is at /var/www/html/moodle1 and the Moodle root for is at /var/www/html/moodle2.

At the bottom of the httpd.conf file there should be a Virtual Hosts section. You will need to uncomment and add the following lines in your httpd.conf file.

Use name-based virtual hosting.NameVirtualHost *:80

<VirtualHost *:80>


DocumentRoot /var/www/html/moodle1


This section allows for the use of .htaccess files to enable Shibboleth on directories

<Directory "/var/www/html/moodle1">

Options All

AllowOverride All

Order allow,deny

Allow from all


This section is required by Moodle to use Shibboleth authentication along with local authentication by only restricting the index.php file to shib auth.

<Directory /var/www/html/moodle1/auth/shibboleth/index.php>

AuthType shibboleth

ShibRequireSession On

require valid-user



<VirtualHost *:80>


DocumentRoot /var/www/html/moodle2


This section allows for the use of .htaccess files to enable Shibboleth on directories

<Directory "/var/www/html/moodle2">

Options All

AllowOverride All

Order allow,deny

Allow from all


This section is required by Moodle to use Shibboleth authentication along with local authentication by only restricting the index.php file to shib auth.

<Directory /var/www/html/moodle2/auth/shibboleth/index.php>

AuthType shibboleth

ShibRequireSession On

require valid-user



Save and close the file and check the apache configuration: httpd -t Then restart apache. sudo /sbin/service httpd restart

Configure Moodle to use Shibboleth authentication and local login

For this to work you need to have the require shibboleth directives only restricting the index.php file in the auth/shibboleth/ directory. You can then put a link to auth/shibboleth/index.php page in the login page and should be able to login with both local and shibboleth accounts.

#1. As Moodle admin, under Site Administrator, browse to Users → Authentication → Shibboleth.

#2. Fill in the fields of the form. The fields ‘Username’, ‘First Name’, ‘Surname’, etc. should contain the name of the environment variables of the Shibboleth attributes that you want to map onto the corresponding Moodle variable. For Shibboleth 2.1, these are set in the attribute-map.xml file.

##################################################################### Shibboleth Attributes needed by Moodle: For Moodle to work properly Shibboleth should at least provide the attribute that is used as username in Moodle. It has to be unique for all Shibboleth Be aware that Moodle converts the username to lowercase. So, the overall behaviour of the username will be case-insensitive. All attributes used for moodle must obey a certain length, otherwise Moodle cuts off the ends. Consult the Moodle documentation for further information on the maximum lengths for each field in the user profile. #####################################################################

#3. Save the changes you made on the Shibboleth page.

#4. Browse to Users → Authentication → Manage Authentication to Enable and Disable Shibboleth login. You can control the priority of the failthrough here if you would like as well.

#5. Save the changes.

CCLE UCLAlogin.php page

If you are going to use CCLE UCLAlogin.php page you will need to edit the htpswwwroot variable and hard code the server name.

Example for Comment this line://$CFG->httpswwwroot = str_replace("http://", "https://", $CFG-httpswwwroot);Enter this instead:$CFG->httpswwwroot ="";

rsync without prompting for password

Whenever you need to use scp to copy files, it asks for passwords. Same with rsync as it (by default) uses ssh as well. Usually scp and rsync commands are used to transfer or backup files between known hosts or by the same user on both the hosts. It can get really annoying the password is asked every time. I even had the idea of writing an expect script to provide the password. Of course, I didn’t. Instead I browsed for a solution and found it after quite some time. There are already a couple of links out there which talk about it. I am adding to it…

Lets say you want to copy between two hosts host_src andhost_dest.

host_src is the host where you would run thescp, ssh or rsyn command, irrespective of the direction of the file copy!

  1. On host_src, run this command as the user that runsscp/ssh/rsync$ ssh-keygen -t rsa

    This will prompt for a passphrase. Just press the enter key. It’ll then generate an identification (private key) and a public key. Do not ever share the private key with anyone! ssh-keygen shows where it saved the public key. This is by default ~/.ssh/

    Your public key has been saved in <your_home_dir>/.ssh/

  1. Transfer the file to host_dest by eitherftp, scp, rsync or any other method. cat ~/.ssh/ | ssh username@hostname ‘cat >> ~/.ssh/authorized_keys’
  1. On host_dest, login as the remote user which you plan to use when you run scp, ssh or rsync on host_src.
  2. Copy the contents of to~/.ssh/authorized_keys
    $ cat >>~/.ssh/authorized_keys
    $ chmod 700 ~/.ssh/authorized_keys
    If this file does not exists, then the above command will create it. Make sure you remove permission for others to read this file. If its a public key, why prevent others from reading this file? Probably, the owner of the key has distributed it to a few trusted users and has not placed any additional security measures to check if its really a trusted user.

  1. Note that ssh by default does not allow root to log in. This has to be explicitly enabled on host_dest. This can be done by editing/etc/ssh/sshd_config and changing the option ofPermitRootLogin from no to yes. Don’t forget to restart sshd so that it reads the modified config file. Do this only if you want to use the root login.

Well, thats it. Now you can run scp, ssh and rsync on host_src connecting tohost_dest and it won’t prompt for the password. Note that this will still prompt for the password if you are running the commands on host_dest connecting tohost_src. You can reverse the steps above (generate the public key onhost_dest and copy it to host_src) and you have a two way setup ready!

Upgrading MySQL


I recently upgrade a MySQL database server from version 4.0.x to 5.0.x. I ran into a couple issues while trying to import the mysqldumps of the databases. I figured I would write about it.


Error 1064 (42000)

I was getting the following error while trying to import the mysqldumps of certain databases.  Here was a couple of the solutions:

#1 An invalid character in a table or column name.  In my particular case it was a dash.  Version 5.0.x no longer allows dashes in table or column names.

#2 There are certain reserved words in MySQL5 and the mysqldump from version 4.0.x  wasn’t escaping them properly for the import.  I was able to rename the reserved words from something like option to tempoption and import the mysqldump. Then through phpMyAdmin I was able to rename the table or column name back to the original reserved word.  Here is a reference of reserved words in MySQL 5.0.x