For that purpose I’ll write down the two solutions that I know of, one easy solution and a more complex solution.

Overview

The tools we’re going to be discussing here are:

• StarDeploy: http://www.stardeploy.com
• Munki: http://code.google.com/p/munki/

Both are good tools, but I’ll go ahead and say that Munki is far better for enterprise environments.

After reading this article I hope you’ll agree ^_~

StarDeploy

Let us start with the easy one, StarDeploy.

This product is fairly new but already does a nice job in updating third party software.

How StarDeploy works

StarDeploy is very easy to setup, it works with just two components:

• On the server you need an AFP share for StarDeploy. This share contains all the applications or packages, etc.
• On the client side you need the actual StarDeploy application, this application runs as root and connects to the AFP share. It uses rsync to update .app files and download packages. That way it knows when something is new.

You can read about the details in the StarDeploy manual, it’s a well written document (ignore the grammar) and with it you can easily learn all about how StarDeploy works and what all the files and folders mean.

So when reading this you can imagine it’s very easy to setup and maintain. The downside though of this concept is that it updates immediately, even if a user has an application opened it will (forcefully) update the files using rsync which may cause some “inconvenience” for the users.

Though if that’s acceptable in your setup then this solution is perfectly fine.

Pros & Cons of StarDeploy

StarDeploy comes with many advantages, especially if you compare it to relying on e.g. ARD. But it also has a few disadvantages which might not be acceptable in every situation.

Pros

• Easy to use and easy to setup, anyone can do it.
• Easy to maintain, again anyone can do this.
• It can update/install .app files.
• It can run package installers (.pkg, mpkg).
• It can set system wide library settings or files (e.g. managed fonts, etc.).

Cons

• It updates even when applications are opened.
• It can’t do Apple software updates. Meaning you’ll need to find another solution for this. I’ll give you my idea on this topic.

As I mentioned before, if the cons are acceptable in your situation then this tool will be perfectly fine.

Configure StarDeploy on the server

The first thing you’ll need to do is setup the server side, which basically means that you’ll need to setup an AFP share.

What I did was create an AFP share called “deploy” and inside the share I created the directories required by StarDeploy:

• Applications
• Library
• Packages
• Users

Your all done on the server side when the AFP share and required directories have been created.

For testing purposes I’ve uploaded a few applications to the Applications directory inside the deploy share (Firefox, OpenOffice.org, Opera, etc.), all .app files that will get synced to the client.

Install StarDeploy on the client

And the second part is installing the client application, which is as simple as installing the application package on a client Mac. (can be done with ARD)

Once the application is set you can setup the application from your system preferences, the main part here is entering the AFP share (afp://<yourserver>/deploy/) and maybe tinker with the other settings a bit. This part is really easy to understand so I’m not going to bore you with screenshots.

From the StarDeploy preferences you can force the sync right away, and here for testing purposes I’ve made sure that the above applications don’t exist on the client Mac.

If you follow the logs you’ll see that it rsyncs just about everything, in case of .app files it syncs them directly to the /Applications directory. Which is the same for Library files. Package files are first rsynced towards a local StarDeploy directory from where it runs the package.

Another thing for the client side is that you can install Growl to give notifications when StarDeploy is doing it’s job, I never got that to work but this could give a user the heads up that something is changing. It tells the user when StarDeploy starts it’s run and when it’s done.

Update plan with StarDeploy

As I mentioned, this tool can update all third party applications (with some work even Adobe) but it won’t do the Apple updates for you.

In our case I came with the following solution for that part:

• StarDeploy:
  • Does hourly updates. In my testing I found that StarDeploy is launched with Launchd, it uses a .plist file (obviously) but it has an interval time in that .plist. So it calculates the daily interval based on the moment it’s first launched, not very accurate. An hourly update in my eyes is safer and lets face it, it won’t do something every hour but only once a day (first time it runs).
• Workgroup Manager:
  • Using WGM you can setup a computer policy telling the computer when to shutdown and when to turn itself on (this works). What I did was set the policy to turn off all computers on a friday evening (22:00) and turn them back on on a monday morning (05:00).
• Apple Remote Desktop:
  • Knowing that all Macs are turned on on 05:00 I can create an ARD flow that does the updates. Basically one Unix command that you send to all the computers and once the Unix command is done you send a shutdown command to all computers. You can schedule these commands one minute apart, thus:
    • Unix command on 05:15.
    • Shutdown command on 05:16.
  • This will queue the two commands, so when the Unix command is done it will shutdown all computers at the same time. The shutdown is necessary, it will simulate the reboot which usually is required.

For the record, this is the Unix command I’m sending:

# Install all Apple software updates
softwareupdate -i -a

# Fix disk permissions
diskutil repairPermissions /

I figured it would be a good thing to regularly fix the disk permissions, but you could leave that one out of the script. The softwareupdate -i -a is the only thing you need for installing all Apple updates.

This gives you a nice “green” solution for keeping all Macs up to date without bothering the users too much.

StarDeploy verdict

StarDeploy does what you’d expect it to do but not with allot of tact, it will forcefully install applications or run package installers for you and overwrite Library or user preferences. On the other hand, it’s very easy to maintain. Just upload an application to the share and all Macs get the update, which is something anyone can do.

So if you need something easy, quick and simple then this is the tool for you. But if you feel your missing something then I’d advise you to read the next part about Munki.

Munki

Munki is a lesser known tool, at least to me it wasn’t known until after I learned about StarDeploy in an article on AFP548.com.

Munki, to me, is the best solution for updating an enterprise environment. I was stunned that the consultants we hired when first migrated from Microsoft to Apple didn’t tell us about this tool for updating the Macs (real shame). If they had done so then we’d have used this tool from the beginning but instead it took us some time to discover these things ourselves. Our background is Linux and BSD, not Mac so we needed to learn how to do things the Apple way which simply takes some time.

This is what Munki writes about their own product:

munki is a set of tools that, used together with a webserver-based repository of packages and package metadata, can be used by OS X administrators to manage software installs (and in many cases removals) on OS X client machines.

munki can install software packaged in the Apple package format, and also supports Adobe CS3/CS4/CS5 Enterprise Deployment “packages”, and drag-and-drop disk images as installer sources.

Additionally, munki can be configured to install Apple Software Updates, either from Apple’s server, or yours.

munki is currently in use at organizations all over the world, managing software for thousands of Macs.

Check out the Wiki for some notes and documentation, and browse and/or check out the source. There’s also an installer package in the Downloads section.

I couldn’t write it better myself, so let’s continue with how Munki works.

How Munki works

Munki is also separated in two parts, a server and client part, but it’s a little more complex compared to StarDeploy:

• Server side:
  • Web service: Similar to how the Apple updates are handled.
  • Munki tools & settings.
• Client side:
  • Munki tools.
  • A plist that contains the client settings. (can be managed using WGM)

Not very complex but you need to do a few more things compared to StarDeploy.

The following pages are the ones that helped me the most when learning how Munki works, I was all set after understanding those documents and experimenting in a test environment:

• Info on what it can do and what clients experience: http://code.google.com/p/munki/wiki/FAQ
• Manual on how to install Munki on a standalone machine: http://code.google.com/p/munki/wiki/InstallingOnStandaloneMachine
• Information on Manifest files: http://code.google.com/p/munki/wiki/Manifests
• Information on how to configure the client plist: http://code.google.com/p/munki/wiki/configuration
• Info on how to manage Apple Software Updates with Munki, this is done inside the client plist file: http://code.google.com/p/munki/wiki/AppleSoftwareUpdatesWithMunki
• Info on Blocking Applications, this feature protects users and notifies them to quit an application before updating it: http://code.google.com/p/munki/wiki/BlockingApplications

Pros & Cons of Munki

Munki is a great tool, but not perfect (nothing is perfect).

Pros

• Munki can install different types of packages:
  • Apple-flat packages (.pkg)
  • Apple-flat meta-packages (.mpkg)
  • Apple-non-flat packages (.pkg)*
  • Apple-non-flat meta-packages (.mpkg)*
  • Drag-and-drop disk images
  • Adobe CS3/CS4/CS5 Deployment “packages” created with Adobe’s Enterprise Deployment tools – CS3 Info CS4 Info CS5 Info
  • Many Adobe CS3/CS4/CS5 product updaters
  • Adobe Acrobat Pro 9.x updater disk images as downloaded from Adobe
• Munki notifies users that updates are available and gives the user the choice of updating. Visually this looks almost the same as the Apple Software Update window.
• Munki can handle the Apple Software Updates.
• Munki can provide a client with optional installs. e.g. programs that not every Mac needs, but users are free to install them when they require such a program. (self service)
• Munki can notify users that they need to close a certain application before updating, this is a safe guard since some applications can behave oddly if they are updated while running.
• Munki is highly configurable, which means you can do just about anything with it.
• The client side can be managed via WGM, because of this the client side is very easy to manage.

Cons

• The server side is harder to manage compared to StarDeploy.

Munki basically takes more effort to manage and to get it working, but that’s limited to the server side since the client side is very easy to manage. So the admins need to do a little more but in return you get something very slick from a users point of view.

Install Munki on the server

Installing Munki on a server is very easy to do, I’ll explain what I did for my testing environment.

• Install the Munki tools.
• Use your Apple web server and add a virtual host to it, this virtual host will point to a directory which will become your Munki repository. I named my virtual host munki. Disable all features for this virtual host, it only needs to enable access to the repository.
  • I’m assuming you know how to enable the web service and add a virtual host to it, I’ll also assume that you know that a virtual host is tied to the DNS name ^_~ The exact details are outside the scope of this article, but feel free to ask if you have some issues with this part.

Lets say your repository is on an external disk:

• /Volumes/DATA/munki

Inside this directory you need to create the following directories/files:

• catalogs: This directory contains the index catalog files, similar to the catalog files used by the apple update service. These index files are manually made, they are based upon the information in the manifest files and the info found under the pkgsinfo directory.
• manifest: Manifest files are plist files that contain configurations that clients get, you can create several for different groups of clients.
• pkgs: Contains package files, this can be .pkg, .dmg, etc. files.
• pkgsinfo: Contains package info files, each time you add an application or update to the pkgs you need to create a pkginfo file (manually) inside this directory.

Also, using the terminal create an empty index.html file inside the munki directory:

touch /Volumes/DATA/munki/index.html

Now that the core files and directories are there we can start by adding a few applications in there as reference.

Creating a manifest file

We will first create a manifest file, this file will be called “testing”, the contents of that file will look like this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>catalogs</key>
<array>
<string>testing</string>
</array>
<key>managed_installs</key>
<array>
<string>Firefox</string>
<string>Camino</string>
<string>OpenOffice.org</string>
</array>
<key>managed_updates</key>
<array>
<string>Firefox</string>
<string>Camino</string>
<string>OpenOffice.org</string>
</array>
<key>optional_installs</key>
<array>
<string>Gimp</string>
</array>
</dict>
</plist>

This covers a few parts of what Munki can do, hopefully it will give you some insight in what Munki can do for you.

Add the applications

As you can see there are 4 applications in this list:

• Firefox
• Camino
• OpenOffice.org
• The Gimp

Download the latest versions of these applications and upload the .dmg files to the pkgs directory (yup the entire dmg file).

When the files are there open up a terminal and execute the following commands, these will create pkginfo files:

# We first go to the munki directory
cd /Volumes/DATA/munki

# Now we execute the command for creating packages
# The syntax looks like this: /usr/local/munki/makepkginfo pkgs/”package” > pkgsinfo/”package”.pkginfo

/usr/local/munki/makepkginfo pkgs/Firefox 3.6.13.dmg > pkgsinfo/Firefox 3.6.13.pkginfo
/usr/local/munki/makepkginfo pkgs/GIMP-2.6.11-Snow-Leopard.dmg > pkgsinfo/GIMP-2.6.11-Snow-Leopard.pkginfo
/usr/local/munki/makepkginfo pkgs/Camino-2.0.6.dmg > pkgsinfo/Camino-2.0.6.pkginfo
/usr/local/munki/makepkginfo pkgs/OOo_3.2.1_MacOS_x86_install_nl.dmg > pkgsinfo/OOo_3.2.1_MacOS_x86_install_nl.pkginfo

Now we’re almost done, all that’s left is creating the catalog file:

/usr/local/munki/makecatalogs /Volumes/DATA/munki

Once the catalog file is created your done on the server side. These last two parts, creating pkginfo files and creating the catalog file is something you’ll have to do whenever you add new versions of software.

Since the server side is now done we can continue with the client.

Install Munki on the client

On the client side the installation is rather easy:

• Install the Munki tools.
• Edit the /Library/Preferences/ManagedInstalls.plist, this plist can be pushed via WGM.

In my case the ManagedInstalls.plist looks like this. It’s still very basic, I might update it in the future:

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>ClientIdentifier</key> <string>testing</string>
<key>SoftwareRepoURL</key> <string>http://<munki repository url></string>
<key>InstallAppleSoftwareUpdates</key> <true/>
<key>SoftwareUpdateServerURL</key> <string>http://<apple update server hostname>:8888/index-leopard-snowleopard.merged-1.sucatalog</string>
</dict>
</plist>

/Applucations/Utilities/Managed Software Update.app

Update plan with Munki

To illustrate the big difference between Munki and StarDeploy I’ll write the situation in Munki’s case:

• Munki periodically checks for updates on the client Mac, if updates are available they are either forcefully installed or managed which means that the user will be asked to click the install button for the updates.

And your done since Munki does all third party updates including the Apple updates. So I’ll say it again, it takes more effort but in the end you’ll have an update flow which is far easier compared to StarDeploy.

Munki verdict

Munki really is a one stop shop for all your update needs, it can do anything and can even force updates, installs or removals if needed.

The downside is that it takes some effort to learn, and a little more effort to configure and manage. But once Munki is running you have a very solid system which can be configured anyway you want.

Conclusion

Both tools can do allot of good things, where one is very easy to manage and the other is a little harder to manage.

In my opinion, if you have the expertise then you should go with Munki. It does everything for you and simplifies your update process immensely, on top of that it can be configured anyway you’d want.

But in the end it all depends on what you need, so before making your choice you should compare both products and weight out which one fits your needs the most.

Social Links

The tool is called StarDeploy, you can find more information on their website:

• http://www.stardeploy.com

If you manage several Macs and want to keep their software up to date then this tool might just make that task allot easier, be sure to check it out.

Social Links

So, when that happens you have to look at the big toys out there and the “real” backup software. But which one?

Enterprise Backup Solutions

The people at District13 Computing have made a very solid PDF file showing you what’s out there and explaining the difference between all the tools.

You can download the PDF here.

The software they did mention but didn’t explain in their document is Retrospect, mainly because it’s already widely used and known. You can find more information on their website. Personally I think Retrospect might be good for big organizations where you need a helpdesk to be able to restore data for users, but I don’t think it’s the best solution.

I like my tools to be accessible via command-line, so my personal favorite in this entire list is BRU Server. It’s pretty much everything you need, can even backup other Unix systems (cross platform) and the graphical tools are pretty good + you can do everything via command-line (thus via SSH). The downside would be that you can’t really delegate access to e.g. a helpdesk, you either have all admin access or no access at all. In allot of situations though that’s not a bad thing, you don’t have to restore backups everyday.

But in addition to just backup software you also need to manually backup a few other items that are otherwise not that easy to restore, namely the MySQL databases that you might have, the Open Directory database and something everyone forgets the Server Admin settings. In the following parts I’ll give you those scripts and a plist example on how to automate that process using Launchd.

Backup Open Directory

The ideal way to backup your OD is to simply use Server Admin every now and then, this will create a sparseimage that you can easily restore using the Server Admin as well. If your OD gets corrupted, or if you need to restore it because of any other reason then those sparseimages really are a life safer!

Because of that you’ll want to automate the backup process, and I’d suggest doing daily backups. The sparseimages really aren’t that big and storage is cheap so that really isn’t an argument.

The following script will allow you to backup the Open Directory to a sparseimage.

Script location: /opt/local/sbin/od_backup.sh

#!/bin/bash

# —
# Open Directory Back-up Script
# —

date=`date “+%Y-%m-%d”`
archive_path=/Volumes/DATA/Back-up/LDAP
archive_name=opendirectory_backup

/usr/sbin/slapconfig -backupdb -noEncrypt $archive_path/$archive_name-$date

This script will make a sparseimage file on my DATA volume in the directory Back-up/LDAP, the file isn’t password protected (I found that the script fails allot if you password protect it) so you’ll have to make sure that this specific backup directory is only readable by the root user and nobody else! The files also have a date time stamp by Year, month and then day (when you then list it will show everything in the correct order).

One thing you should know, this script restarts the OD. Running this script during production hours isn’t really a smart thing to do ^_~

Like you should do with all your personal scripts, this script is stored in the directory /opt/local/sbin (you can also use /opt/local/etc and /opt/local/bin, create them it they don’t yet exist).

I already hinted it but restoring the OD can be done using the Server Admin, but you can also restore using the command-line. The command-line option looks something like this:

/usr/sbin/slapconfig -restoredb “filename”

Backup MySQL

Backing up your MySQL database is just as important, like the OD MySQL isn’t that easy to restore if you don’t create dump files.

The following script will backup your MySQL databases.

Script location: /opt/local/sbin/mysql_backup.sh

#!/bin/bash

# —
# MySQL Back-up Script
# —

# Variables
date=`date “+%Y-%m-%d”`
archive_path=/Volumes/DATA/Back-up/MySQL

# Back-up All Databases
mysqldump –all-databases –user=root –password=**** > $archive_path/mysql_full-backup-$date.sql
sleep 5

# Back-up RoundCube
mysqldump roundcube –user=root –password=**** > $archive_path/mysql_roundcube-backup-$date.sql
sleep 5

This script will backup your MySQL database as a whole + backup a separate database that I have for Roundcube (so much better then the default webmail client). I think it’s best to do it this way, both have a backup of the entire DB and all separate DB’s, you’ll be able to do specific restores and full restores if needed.

Similar to the OD backup this script will write the files to the directory /Volumes/DATA/Back-up/MySQL and create file names with the same date time stamp.

Restoring the databases can be done by using the following command:

mysql –verbose –user=XXXXXXXX –password=XXXXXXXX DB_NAME < /PATH/TO/DUMPFILE.SQL

Backing up Server Admin settings

All the parameters you’ve set in the Server Admin are also pretty important, though allot of them end up in service specific config files. Backing up those settings is pretty easy so I’d recommend this for everyone, and again storage is cheap so just do it ^_~ Backing up these settings makes restoring them a bit easier.

Script location: /usr/local/sbin/serveradmin_backup.sh

#!/bin/bash

# —
# Back-up All Server Admin Settings
# —

# Variables
date=`date “+%Y-%m-%d”`
archive_path=/Volumes/DATA/Back-up/ServerAdmin

# Back-up Server Admin Settings
for s in $(serveradmin list); do serveradmin settings $s > $archive_path/$s-backup-$date; done

This script will store the settings in /Volumes/DATA/Back-up/ServerAdmin directory. It’s actually very simple, it does a list of all the services and simply dumps the config in a file.

Restoring these config files can be done with the following command:

serveradmin settings < “settings file”

This is is the same for all services.

Scheduling via Launchd

As I mentioned it’s best to schedule these backups outside of production times, the best way of doing that is to use Launchd (Apples cron replacement).

In this example I’ll run both backup scripts at the same time, for that purpose I’ve created a third shell script that will do one simple task which is simply run the two scripts od_backup.sh and mysql_backup.sh.

Script location: /opt/local/sbin/backup.sh

#!/bin/bash

# Back-up & Restart Open Directory
/opt/local/sbin/od_backup.sh

# Back-up Server Admin Settings
/opt/local/sbin/serveradmin_backup.sh

# Back-up & Restart MySQL
/opt/local/sbin/mysql_backup.sh

It’s very simple, just one wrapper script that runes the others in sequence. Simplifies the next step which is making the launchd plist.

Launchd is actually very easy once you get the hang of it, the first step is to create a .plist file.

Location: /Library/LaunchDaemons/com.example.backup.plist

<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple Computer//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>Label</key><string>com.example.backup</string>
<key>Program</key><string>/opt/local/sbin/backup.sh</string>
<key>StartCalendarInterval</key>
<dict>
<key>Hour</key><integer>0</integer>
<key>Minute</key><integer>0</integer>
</dict>
</dict>
</plist>

Your own plist files should always go to /Library/LaunchDaemons/ that’s where custom plists go. The above plist is something you would usually do with cron, it runs a command at midnight (time notation is the same as in cron). The naming is important, label and file name need to match (without .plist obviously).

Once the plist is made you need to tell Launchd to govern your script, this can be done with the following command:

launchd load /Library/LaunchDaemons/com.example.backup.plist

Now you can check if Launchd accepted the job:

launchd list | grep com.example

It should show you your plist, if it doesn’t then something in the syntax went wrong (usually during loading a plist it already gives you an error).

Conclusion

Choosing the right tools for the job is very important, Time Machine is nice for very small environments and for use at your homes. But when you run an office environment then you really need to look into “real” backup software that can handle the sheer load of tons of small e-mail files, shares, home directories, etc.

You also need to create separate backups for those parts of your system that are difficult to restore otherwise, e.g. restoring your Open Directory using file restore is very tricky (which one?). Making daily copies of those parts of your system are just as important, so using the above scripts to do those tasks is just as important.

Which tool you should use is entirely up to you, I noted that BRU Server is my personal favorite but this could be different for everyone else. In that respect I’d advice you to first look at what you want, what are the specific requirements in your case, and then look at all the options out there and see which tool does the job for you.

Social Links

For companies this is actually very useful (if not required). You can add your company logo to the login screen and personalize everything making it look far more professional then before (default spacy background + Apple logo, it just oozes professionalism. . .)

Overview

In general the things we will be doing is the following:

• Change the systems default background image.
• Replace the login window logo. (the Apple logo)
• Replace the login window logo text. (the bold text saying Mac OS X, or Mac OS X Server)

Once those are replaced your already done, but I’ll go a bit further then just telling you where those files are and how to do it. I’ll also explain the limitations of the logo and logo text, not everything will fit in there.

Change the background image

Let’s first start with changing the default background image towards something more appropriate, I chose to go with one of the other default backgrounds delivered with Mac OS X. But, if you have a default OS image which you install on all your Macs with e.g. DeployStudio then you can also create your own background image and make it default in your image.

From the terminal with your admin user (or as root via Apple Remote Desktop, without the sudo of course):

sudo defaults write /Library/Preferences/com.apple.loginwindow DesktopPicture /Library/Desktop Pictures/Aqua Blue.jpg

This will change the default background image for the entire system to the fresh and clean Aqua Blue image (a.k.a. the old Apple default).

Now when you go to your login window you’ll have a nice background image, something that will help you create a far more professional look and feel.

Change the login window

This is the more advanced part, it will help you change your login window logo which actually consists out of two images:

/System/Library/CoreServices/SecurityAgentPlugins/loginwindow.bundle/Contents/Resources/applelogo.tif

 

/System/Library/CoreServices/SecurityAgentPlugins/loginwindow.bundle/Contents/Resources/MacOSX.tif

You’ll have to look at these files using the terminal, the Finder miraculously hides half of these files and even after replacing it shows the wrong content (go figure). But, the terminal never lies (it’s your friend ^_~).

The only thing you now have to do is create your own logo as a .tif file (transparent), I used The Gimp for that. These images have the following requirements:

• applelogo.tif
  • Dimension: Maximum width and height is 90×90 pixels.
  • File type: .tif
• MacOSX.tif
  • Dimension: Height is limited to 36 pixels. The width isn’t exactly limited, I’ve managed to get an image in there flawlessly with a width of 221 pixels. It could be wider, I think the actual limit is the width of the login screen, but I never had to make something that wide.
  • File type: .tif

In our case we had a square logo with some text underneath it, for that to workout I split the image in two. The square image in the applelogo.tif and the text went into the MacOSX.tif iamge.

When replacing it’s best to do this using the terminal, create the above images to your liking and save them in the root of your home directory. From there you can use the following command to replace the original images:

# Move applelogo.tif –> applelogo.tif.bac sudo mv /System/Library/CoreServices/SecurityAgentPlugins/loginwindow.bundle/Contents/Resources/applelogo.tif /System/Library/CoreServices/SecurityAgentPlugins/loginwindow.bundle/Contents/Resources/applelogo.tif.bac

 

# Copy your new logo to the correct location sudo cp ~/applelogo.tif /System/Library/CoreServices/SecurityAgentPlugins/loginwindow.bundle/Contents/Resources/applelogo.tif

# Move MacOSX.tif –> MacOSX.tif.bac sudo mv /System/Library/CoreServices/SecurityAgentPlugins/loginwindow.bundle/Contents/Resources/MacOSX.tif /System/Library/CoreServices/SecurityAgentPlugins/loginwindow.bundle/Contents/Resources/MacOSX.tif.bac

# Copy your new logo text to the correct location sudo cp ~/MacOSX.tif /System/Library/CoreServices/SecurityAgentPlugins/loginwindow.bundle/Contents/Resources/MacOSX.tif

This will rename the original file and copy your newly made logo to the correct location, you can use the switch user functionality to check the login window.

Conclusion

It will take a while to correctly make your logo and fine tune everything, at least for me it took a while to get it just right. The end result however is something that will make your Mac computer look more professional, for company desktops or laptops these types of changes really are a requirement.

Considering how easy it is to change the login screen I would recommend this for everyone managing company computers or has his/her own company.

Related articles

• Mac OS X hidden features and nice tips & tricks – Apple – Stack Exchange (apple.stackexchange.com)

Social Links