Microsoft recently released a number of security patches for Office for Mac, including updates for Office 2008, Office 2004, and the Entourage Web Services Edition.

According to a March 16th post on MacWindows.com, however, the Office 2008 update (12.2.4) may trigger the long-standing issue of being unable to save Word .doc & .docx files to a Windows server. If you have not been experiencing problems saving files to a Windows server, be very careful before applying this update!

MacWindows.com has posted several potential workarouuds for this issue, including disabling the autosave/recover feature & changing the owner of the sahre on the Windows server to NETWORK SERVICE.

As always, if you plan to upgrade, make sure you have a recent backup and complete plenty of testing before rolling out this upgrade.

Advertisements

Microsoft recently updated Entourage 2008, releasing the Entourage 2008 Web Services Edition update, a small but noteworthy update that moves Entourage’s feature set a few steps closer to Outlook. The Web Services update abandons WebDAV in favor of the Web Services protocol for all communication with Exchange servers.

According to Microsoft, Exchange Web Services offers a “more robust feature set” and supports an Out of Office Assistant, logging, and improved Autodiscover and synchronization services. Stability and compatibility between email clients is improved by shifting responsibilities from client applications to the server.

System Requirements:
  • Intel, PPC G5 or PPC G4 processor (500MHz & higher)
  • 512MB of RAM
  • OS X 10.4.9 or later
  • 1.5GB of free hard drive space
  • Microsoft Office SP2 (12.2.0) or higher
  • Microsoft Exchange Server 2007 SP1 with Connectivity to Update Rollup 4 or higher (Mailbox & Client Access servers)

NOTE: The Entourage 2008 Web Services Edition is NOT compatible with Microsoft Exchange Server 2003 or earlier. If access to earlier versions of Microsoft Exchange Server is required, do not apply the Entourage 2008 Web Services Edition update.


A comparison of features offered by WebDAV and Web Services:

Function Entourage 2008(Uses WebDAV and Exchange Web Services) Entourage 2008, Web Services Edition
Provides logic for calendaring (such as handling meeting and calendar events) on the server Feature not included Feature Included
Synchronizes tasks with the Exchange server Feature not included Feature Included
Synchronizes notes with the Exchange server Feature not included Feature Included
Synchronizes categories with the Exchange server Feature not included Feature Included
Includes interoperability with Exchange server business logic Feature not included Feature Included
Provides GAL details Feature not included Feature Included
Enables meeting attachments Feature not included Feature Included
Provides logging Feature not included Feature Included
Enables Autodiscover service for hosted accounts Feature not included Feature Included
Synchronizes contacts with Exchange server Feature Included Feature Included
Enables implementation of corporate archival policies by using managed folders Feature Included Feature Included
Exposes attendee free/busy information Feature Included Feature Included
Enables delegate management (such as setting on-behalf rights) Feature Included Feature Included
Enables delegate access Feature Included Feature Included
Provides additional out-of-office settings, such as separate internal and external out-of-office messages Feature Included Feature Included
Provides access to Exchange server over HTTP Feature Included Feature Included
Synchronizes folders and items Feature Included Feature Included
Enables proxy auto-config (.pac) files Feature Included Feature Included
Resolves ambiguous names Feature Included Feature Included
Enables meeting reminders Feature Included Feature Included
Provides public folder support Feature Included Feature Included
Enables Spotlight search Feature Included Feature Included
Supports integrated Windows (Kerberos and NTLM) authentication and client certificate-based authentication

Feature Included Feature is included Feature not included Feature is not included

snowleopard.jpgMy last post looked at an issue where network users without a proper path assigned to their home directory in WorkGroup Manager would be unable to properly create a local home folder. This post looks at an issue with login failures that can arise with mobile network accounts under Snow Leopard Server. If you have mobile network accounts – AD or LDAP – that cannot login, jump to the bottom of this post for the fix.

After creating several network user accounts under Snow Leopard, I found that my test user account was unable to login. But instead of the standard shake of the login window that indicates a failed login attempt, the login window actually began to collapse as if the login process was starting – the login & password boxes disappeared briefly before reappearing suddenly & displaying the familiar shake to indicate that login had failed.

Interestingly, the user account could still be used to access system services without issue. Attempting to login to AFP shares or setup iCal for shared calendaring using the users login credentials worked fine.

Several reboots & rebinds later I dug through the system log to find the following error: error = Error Domain=NSOSStatusErrorDomain Code=-35 “Operation could not be completed. (OSStatus error -35.)” (no such volume).

Turns out the ManagedClient.app was unable to create the mobile account at login. The solution was to create it manually. On the client computer, login as an administrator & run the following two commands as root:

sudo /System/Library/CoreServices/ManagedClient.app/Contents/Resources/createmobileaccount -n username

sudo createhomedir -c -u username

This forces the creation of both the mobile user account & their home directory. Log out & log in with your mobile user’s credentials – you should be able to login without issue. This should work for both Active Directory and Open Directory mobile user accounts.

Thanks to Rich Trouton of the macenterprise google group for posting the fix!

As of this writing, Snow Leopard Server is at version 10.6.1

snowleopard.jpgUPDATE: Due to some errors on my part, I have had to heavily edit this article. The information contained herein is now accurate. Sorry for the confusion!

I recently ran into a bit of an irritating issue while setting up directory services on a new server running Snow Leopard Server (10.6.1). It seems that as of 10.6, users without a value for their home directory (NFSHomeDirectory) are unable to create a home directory on managed clients. I had created a series of users and assigned them to groups. Every time I would log in to test, however, error messages would appear warning about problems creating the user’s home directory.

What is interesting, however, is that users can still access system services (AFP, iCal, etc) without issue. Attempting to login to AFP shares using the users login credentials works fine. Attempting to login to a managed client, however, generates a warning message about being unable to locate the users home directory. When logged in, the user cannot create new files or folders on the desktop – the whole system behaves as if the user has no permissions for the desktop.

A quick look at the logs on the server hinted that the issue was tied to home directories, with several warning messages about problems with home directories: CFPreferences: user home directory at /99 is unavailable. User domains will be volatile.

Sure enough, when I looked in WGM, I had forgotten to assign home directories to the accounts. I quickly corrected this (relatively large) oversight & BAM! clients were logging in without issue!

This is a fairly sharp departure from previous behavior. Prior to Snow Leopard, network users with no home directory assigned (NFSHomeDirectory=99) could still login; their home directories were simply created in a folder named “99” in the root of the boot volume (/99/user1). As of 10.6 this behavior seems to have changed. Why exactly, I’m not yet sure – although I imagine it must be tied to security.

My next post explores an issue where mobile account creation can sometime fail on login. Stay tuned!

As of this writing, Snow Leopard Server is at version 10.6.1.

iphone_homeApple’s recently released iPhone OS 3.1 has caused headaches & more than a little confusion for some users with Microsoft Exchange accounts. While the OS 3.1 update improves security policy adherence for iPhones when connecting to Exchange Servers, it also has the unfortunate side effect of breaking security compatibility with pre-3GS iPhones & all but the most recent iPod touches. The end result: many iPhone users who upgraded to OS 3.1 suddenly fond they could no longer sync with any Exchange Servers!

Fortunately, the synchronization issue is limited to Exchange 2007 Servers running SP1 & above, & there is a work-around to re-enable synchronization. Unfortunately, the work-around requires either convincing Exchange administrators to create a security policy exception or rolling back to OS3.0 on the iPhone.

In order to re-enable Exchange syncing with pre-3GS iPhones, Exchange administrators will need to create an EAS policy exception that will allow connections to mobile devices that do not support device encryption (either globally or on a per-user basis).

If the creation of policy exceptions is not an option (& that will likely be the case more often than not) there are 2 options: 1) upgrade to iPhone 3GS or one of the latest 32GB or 64GB iPod touch models, or 2) rollback to OS 3.0 (what will undoubtedly be the most popular solution).

The easiest way to rollback to OS 3.0 is obviously to restore the phone from a recent backup using iTunes (you did create a backup before you upgraded your phone, didn’t you???). Apple has a support article detailing how to backup, update, & restore iPhones & iPods. In case of emergency (ie: no recent backups!) you can go to this site to download firmware for iPhones & iPods. [NOTE: This site is NOT supported by Apple in ANY way!!!)

Finally, Apple has also updated it’s Enterprise Deployment Guide for iPhones. If you’re a sys-admin involved in the deployment & management of iPhones &/or iPods in an enterprise environment, this doc is a must-read.

wgmCreating network home folders for users in Open Directory is typically a fairly painless task using OS X Server. What can be a little more painful is trying to figure out how to create a clean, locally cached home folder on a client workstation. The only obvious options for home folders in Workgroup Manager are None & the creation of an AFP or NFS share that’s stored on the server.

While leaving the settings in WGM set to None does result in the home folder getting cached on the local machine, it’s a less than perfect solution. For starters, the profiles get cached in the root of the drive, under a directory labelled 99. Plus the home folders it creates doesn’t have the usual directory structure – they only contain a Desktop and a Library folder. Not quite what we’re looking for. Ideally, the home folder would get created in the /Users directory, using the standard home folder template just like a local machine account is.

The fix to this is to make sure the NFSHomeFolder attribute is set for all your network accounts. That’s what happens when you select an AFP or NFS share – the path to the network share is written to the NFSHomeFolder attribute in the LDAP directory. When you leave the home folder setting at None, the default value is assigned to NFSHomeFolder – a value which happens to be 99 (hence the 99 directory that appears in the root directory on client machines whenever a user without a specified home folder logs in).

Set Network Account Home Folders to the Local Users Directory (/Users):

  1. Launch WGM & login to your Open Directory server
  2. If the Inspector tab in WGM isn’t visible, enable it in the Preferences
    1. Check the box next to “Show ‘All Records’ tab and inspector
  3. Select a network user account & click the Inspector tab
  4. Locate the NFSHomeDirectory attribute – it should read 99 – & change this value to ‘/Users/username‘ where username is the shortname of the user.
  5. Save your changes.

entourage_mac_2008_iconWhile most of the blog coverage on the recent Office 2008 12.1.9 Update focused on the patching of Word vulnerabilities, considerably less attention was paid to what seems to me to be a much more important aspect of the update: Exchange Web Services support.

Entourage Web Services is Microsoft’s upcoming attempt to “achieve greater parity between Entourage and Outlook.”

According to Microsoft’s Description of the Microsoft Office 2008 for Mac 12.1.9 Update, this update is a “prerequisite for the installation of Microsoft Entourage 2008 for Mac Web Services Edition” and will have to be installed before the Entourage 2008 Web Services Edition can be installed.

Microsoft will be abandoning CalDAV for Exchange Web Services (EWS), which should offer better “performance, compatibility, and reliability” since EWS allows Entourage to shift the bulk of the ‘heavy lifting’ to the exchange server, rather than relying on the client to carry the load as it does now. It will also allow for the syncing of Tasks, Notes, and Categories with an Exchange server and will use EWS & HTTP to resolve names from the Global Address List, among other features.

Entourage for Exchange Web Services requires Exchange Server 2007 running Service Pack 1 with Update Rollup 4 or greater. Clients need to be running OS X 10.4.9 or later and the 12.1.9 update for Office 2008 for Mac, plus the Entourage for Exchange Web Services Edition (once released). More information on the Entourage for Exchange Web Services Edition can be found at The Office for Mac Team Blog.

Entourage Web Services is still in the beta stage, however, and not yet available to the general public. Its inclusion in the 12.1.9 update seems to imply that that may soon change.

Update to version 12.1.9 of Office update using the Auto-Update tool, or download the 12.1.9 update directly from Microsoft’s support site.

As with all software updates to mission critical software, please be careful.

disk_utility_icon

I recently had a drive fail in a client’s RAID setup. 3 mirrored drives in a software RAID0 (mirrored) configuration. No big deal, you say! In a 3 drive configuration like that, you can swap the faulty drive without even losing any redundancy! Simple!

Right.

Physically replacing the drive went as planned, dead easy. But the rebuild failed contiuously. It should take hours (they were terabyte drives) but instead would stop after a few minutes, showing the replacement drive status as “Failed”. RAID Status obviously remained “Degraded”.

A bit of digging around on the web turned up this Apple knowledgebase article on rebuilding software RAID mirrors, which pointed out two VERY usefully pieces of information:

  1. You should use the command-line diskutil for rebuilding a RAID. Sometimes Disk Utility will be unable to successfully
    rebuild a degraded RAID mirror.

    • (Not an issue, this is standard practice anyways.)
  2. You should not rebuild the rebuild a mirror while it is the boot volume. Rebuilding a RAID Mirror will sometimes fail if it is the boot volume.
    • (Major issue, as it defeats much of the benefits of running a RAID in the first place! Sure, the data is safe – VERY important – but now I have to take a mail server offline for 12hours while the RAID rebuilds?!?!?)

The successful rebuild of the mirror involved both the above steps. The mail server was booted to an external drive and diskutil was used to rebuild the mirror. Before doing anything, however, I created a backup image file of the server (just to be safe…). The server was offline for approximately 12 hours, but it might have needed less – once I was confident that the rebuild was progressing successfully, I tried to enjoy the rest of my Saturday.

The moral of this story is obviously that software RAID solutions are in no way a substitute of hardware solutions. If you need guaranteed uptime, you need to invest – but we all knew that already… right?

For more information on rebuilding a software RAID in OS X, read Apple’s knowledge base article: How to rebuild a software RAID mirror.

AlienRAID.org

June 2, 2009


AlienRAID Logo

I just recently stumbled onto a very interesting website, AlienRAID.org, a site dedicated to “supporting Apple Xserve RAID storage systems in non-Apple environments.” Interested in Xserve RAIDs running at the South Pole? Or running Windows Server on an Xserve? This is the site for you.

IT staff & admins only – I don’t know how much there is here for your average end user…

Visit AlientRAID.org.

remote_desktop_128Using kickstart to activate ARD is something that I do all of the time, yet I can never seem to remember the syntax. I figure I can’t be the only one in this situation (plus this post should save repetetive googling…) so I thought I would post it up where it’s easily accessible. The following commands work with ARD v2 & later. For earlier versions of ARD, see this knowledge base article.

You need SSH access to the computer you would like to enable ARD on (obviously) & you need to login as root or run the command with sudo. Services are started using the kickstart utility, located here:

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents /Resources/kickstart

To activate Remote Desktop Sharing, enable access privileges for the user “admin” with full privileges and restart the ARD Agent:

$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents /Resources/kickstart -activate -access -on -users admin -privs -all -restart -agent

Deactivate Remote Desktop Sharing:

$ sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents /Resources/kickstart -configure -access -off

To additional examples and more detail, see the complete knowledge base article.