How To Make Mac OS X Do Windows update from July 2004

Discover how new tools and features in the enterprise-friendly OS help you integrate your Mac users' workstations into your Windows environment.

July 22, 2004

10 Min Read
NetworkComputing logo in a gray background | NetworkComputing

No one likes to admit it, but there's something appealing about single-vendor implementations: If 95 percent of your end nodes are Windows, it would be easier to manage your network if the other 5 percent were, too.

Truth is, most organizations have at least a handful of die-hard Macintosh users--sometimes an entire department. Mac users are fiercely loyal to their boxes, by preference or by necessity, for nichey Mac programs such as Adobe Photoshop, Apple Final Cut Pro and QuarkXPress. With an Ethernet card and IP stack, these devices can connect and transmit data on your IP network, but they can't necessarily print or access shared files.

Since Apple switched architectures a few years ago, most Mac users have embraced the classic System 7 operating system or turned to the newer Mac OS X derived from Unix. Not surprisingly, System 7 is harder to integrate with Windows systems because the older OS doesn't have good support for non-AppleTalk-based file and print sharing, Terminal Services clients and domain authentication. Moreover, it can't run natively on newer Apple hardware.

But you can resolve Mac-Windows integration problems using the more enterprise-friendly Mac OS X. One benefit of OS X is that it doesn't require AppleTalk, which comes with the operating system but is turned off by default. AppleTalk has gotten a bad rap in the enterprise for being chatty and inefficient, and requiring an additional network protocol stack on servers and routers. It makes more sense for small networks because it automatically configures addresses and discovers nodes, so you don't need DHCP or DNS servers.

Mac OS X comes with a Windows file-sharing client, Active Directory integration and support for classic Mac applications. Users of System 7 Macs can get some cross-platform functionality by using Thursby Software Systems' DAVE.

The main areas of Mac-Windows integration are file sharing, printing, authentication, remote administration and support for Windows applications.

File and Print

Mac OS X users can connect to a Windows share using the built-in Samba client. Samba uses the native Windows file-sharing protocol SMB (Server Message Block), which lets the Mac connect via IP using a Windows-native protocol. That's a big improvement. In the past, the only way to connect was via AppleTalk, and you had to run "File Services for Mac" on the Windows box first, or buy a third-party add-on, such as DAVE.

We've used the Samba client for connecting to both Windows NT and 2000 servers in our Syracuse University Real-World Labs®. The Mac user selects "Connect to Server" from the Go menu, types in an IP address or server name, and authenticates. He or she also can specify a workgroup or domain. From there, the user can mount a shared volume, and the Windows server needs no modifications. The user can also store his or her home directory on a Windows file server, though Apple recommends using an AFP (Apple File Protocol) or NFS server.

There are advantages to using shared directories for file storage and retrieval. Centrally stored files are accessible from multiple computers. More important, it's easier to back up one file server than multiple workstations.

Most OS X versions can share drives and folders with Windows users via SMB, but version 10.3 comes with additional features. Its OS X Directory Access utility, for instance, lets you specify a workgroup to join, as well as a WINS server to resolve Windows names.

Apple Mail.app supports Exchange mailboxes and address book synchronization with an Exchange server. However, you must enable IMAP on the Exchange server. The new Mail.app also has a "send Windows friendly attachments" option, which is a step up from previous versions, where file attachments sent to Windows users were sometimes corrupted or unreadable.

Print sharing with Mac OS X has never been simpler. Mac, Unix and Windows machines can print to an LPR (Line Printer Remote)-enabled printer or print server, which is available in Windows NT and 2000 print servers. Make sure you enable the service on your printer or print server. Some higher-end and corporate-class printers have LPR built in, requiring the OS X user simply to enter the printer's IP address. OS X 10.3 also supports shared Windows printers via SMB, though we prefer LPR, since it's the most compatible cross-platform printing protocol out there.

If your Mac user can't connect to the printer, it may be because the printer doesn't have a Macintosh OS X driver. And some printers may be directly connected to a Windows machine and not networked. This isn't a networking issue per se, but some departments may have a high-end, specialized printer connected to PCs running Windows, for instance, or one PC color inkjet printer in an office full of monochrome laser printers. The best work-around is to print to a PDF file as an intermediate step, which will preserve text formatting and embedded graphical elements, then print from a PC.

A Mac OS X machine can authenticate users against an LDAP directory, Novell eDirectory and NIS, and OS X 10.3 can authenticate natively to an Active Directory domain. Previous OS X versions could authenticate to AD only via LDAP, which wasn't easy.

Version 10.3 also takes advantage of single sign-on, which requires using an FQDN (Fully Qualified Domain Name) to connect to the AD server, versus using WINS resolution.

OS X's Directory Access application, located in /Applications/Utilities, lets you configure AD directory information. The Mac user enters the AD forest and domain DNS names, as well as his or her computer ID. Once the user authenticates, the Mac is added to the domain.

Making the Mac a part of the domain is a relatively new but powerful feature. Users no longer need separate Mac and domain login passwords, and user accounts don't have to be created manually on every Mac for every user. Nor do you need to buy and install an OS X Server to handle centralized logon capabilities.

By slightly modifying the AD schema, you can manage and run login scripts. And you can specify which AD groups are granted administrator access to the Mac. This lets you centrally control which admins get root access on the Mac. Plus there's an option to cache the last login information for offline operation. You also can use the command line to get a Mac to join a domain remotely. Log into the Mac through SSH (Secure Shell) and execute the dsconfigad command as root:

dsconfigad -a $computername -u $username -p $password -ou "LDAP DN of container for the computer" -forest FQDN -domain FQDN

You can leave off the password field and enter it manually, but you must specify a user name on the command line. Close the AD configuration screen and click on Authentication. Select "custom path" from the search order and add the AD plug-in. Once you reboot, OS X 10.3 users can authenticate against AD. This process also can be done on the command line, and it requires no modifications to the AD schema. Any new users logging in will have a local home directory created automatically. Mac-specific schema additions are available for managing Mac clients. For more details, see Apple's white paper on AD integration.

For connecting graphically to Windows servers, Microsoft has released a Mac Remote Desktop Connection client at www.microsoft.com/mac/otherproducts/ otherproducts.aspx?pid=remotedesktopclient.

Going the other direction--Windows to Mac OS X--is a different story. Although Apple does have a remote desktop viewer, it's not available for Windows. Instead, an admin must remotely connect to a Mac via SSH. This gives you a command line-driven shell, not the GUI. You can write shell scripts for administration, running reports and installing software, for instance, as with your existing Unix and Linux machines.

Forcing the installation of OS patches is one of the most important tasks for centralized management, and OS X lets you remotely install patches quickly and easily. OS X shell scripts and command-line tools automate the procedure: Log into the Mac first via SSH, then issue a softwareupdate command. In OS X 10.3, issue softwareupdate -l. The Mac will check with the Apple software update servers for new releases. Just obtain root privileges and type softwareupdate . OS X 10.3 requires softwareupdate -i . To reboot, type /sbin/reboot.

Sometimes, a Mac OS X user must run a Windows application. Although Microsoft has released Internet Explorer for Mac, it's not equivalent to its Windows counterpart. We've run across Web sites that will work only in IE for Windows. Rather than giving users both a Mac and a PC, you can run Windows on a Mac through an emulator like VirtualPC for Mac, made by Connectix and recently bought by Microsoft. VPC emulates a complete PC system so an OS X user can run Windows, or any other i386 OS, simultaneously with OS X. The software by itself costs $129, but you need a Windows license. VPC with an included XP Pro or W2K license costs $249.

Supporting Mac users on your network is getting a lot easier. The new tools and capabilities in OS X that integrate these workstations with your Windows environment make your Macs feel right at home.

OS X 10.3: How to Join an Active Directory domain

Make sure Active Directory has a fully qualified domain name. OS X 10.3 can't connect to AD over WINS resolution, so check with your DNS administrator.

Open the Directory Access utility, or use the dsconfigad command-line tool. The Directory Access utility is located in /Applications/Utilities. The command line can be accessed from the "Terminal" application.

Enter the AD forest, domain and computer ID. You can easily get the forest and domain from your AD administrator. The computer ID is the Mac's network name.

Authenticate with appropriate access rights. You need a user name and password, with permissions to create computer objects in the domain.

Add the Active Directory domain to the authentication search path. We needed to do this step to get our Mac to authenticate against a domain, though we've heard it isn't necessary. If your Mac doesn't authenticate to the domain, try this and then reboot.

Local home directories are automatically created when a new user logs in. If you create local accounts on the Mac before joining the domain, a domain user name could be the same as a local one. In that instance, the Mac authenticates locally instead of against the domain.

Michael J. DeMaria is an associate technology editor based at Network Computing's Syracuse University's Real-World Labs®.

Back in 1991, Apple created a feature that let you make an alias or shortcut to a networked Windows file share. Users could double-click on the alias to connect to the share instead of using a network browser. It was a great feature for connecting to frequently used servers, and it's still available in OS X.

Apple has resurrected another feature in OS X: the keychain, a central repository of user names and passwords. It first came with System 7 Pro, but was later removed because it didn't catch on. The keychain, aimed at organizations where the Mac user can't take advantage of single sign-on capabilities or join the domain, lets a user quickly connect to multiple servers, even with different login IDs and passwords. It also extends to mail server and VPN authentication. The keychain stores login credentials in an encrypted format, which can be retrieved by entering a master keychain password.

When connecting to a network share, users can store their credentials in the keychain to avoid having to remember login information for various servers. They use a master password. The benefit: They can create more complex and diverse passwords. The trade-off is that users can also easily forget them.

SUBSCRIBE TO OUR NEWSLETTER
Stay informed! Sign up to get expert advice and insight delivered direct to your inbox

You May Also Like


More Insights