As part of a project to assess the deployment options for National Instruments’ LabVIEW 2013 Pro, I was asked to see if I could deploy it through Casper’s Self Service. After some work, I was able to repackage the installer in a way that deploys smoothly. In the process, I saw a number of ways that this particular installer went against The Commandments of Packaging. See below the jump for details.
One of my users ran into an issue recently when launching Microsoft Lync. When the Lync application logged into the Lync server, a Microsoft Lync wants to use OC_KeyContainer_username@company.com. Please enter the keychain password prompt appeared.
The curious thing was that the keychain prompt would not accept the user’s current login password. When I checked, the user’s login keychain was unlocked and using the current password, so it didn’t appear to be caused by the login keychain password issues that I normally deal with.
After some research, I was able to find the answer and get this issue fixed. See below the jump for the details.
Upgrading a FileVault 2 encrypted Mac to 10.9 – Differences between CreateOSXInstallPkg and Apple’s Mavericks installation methods
I was recently wrong on the internet again, but as always making a mistake gave me a chance to learn from it. What I learned was the method Mac admins choose to use upgrading their Macs to Mavericks may have behavior that apply specifically to FileVault 2-encrypted Macs. See below the jump for details.
As part of a domain migration project, I was recently tasked with figuring out a way to handle migrating the Macs from one AD domain to another. I had the following requirements:
- Unbind the Mac from the old AD domain
- Bind the Mac to the new AD domain
- Migrate the user’s data from the old AD domain to the new AD domain
Preferably, it would be a procedure that anybody could use. That way, anyone on the team could be perform the migration process regardless of their personal skill level with Macs.
I had a pre-existing interactive script that I could modify and use to fulfill requirement 3, but I needed a way to fulfill requirements 1 and 2.
With some help from DeployStudio, I was able to develop an unbind / rebind procedure that fulfilled requirements 1 and 2. It also gave me the following features:
- Anyone on our helpdesk team could do it, regardless of familiarity with Macs or Active Directory.
- Potential for human error was minimized
- Reboots (generally a good idea when making directory service changes) were a built-in part of the migration process.
For details, see below the jump.
A while ago, I needed to script a method for binding Macs running 10.6.x and later to our Linux-based OpenLDAP server. Recently, we needed to move our OpenLDAP domain to a different OpenLDAP domain as part of a larger directory service migration project. A small part of that project was moving the LDAP-bound Macs to the new LDAP domain, preferably with as little disruption as possible.
One enormous advantage I had with this LDAP move was the following:
All UIDs, GIDs, usernames, passwords and group names were going to be identical between the two LDAP domains.
As a consequence, I would not need to do any permissions changes, rebuild accounts, make sure people got new passwords or a host of other things normally associated with a directory service change. My task was essentially to tell the Macs “Stop talking to the OpenLDAP service at that address, start talking to this other OpenLDAP service at this address”
As part of the project, I also wanted to accommodate two separate Active Directory domains differently. I wasn’t binding to AD as part of this process, but if a particular Mac was bound to Domain A, I wanted to unbind. If a Mac was bound to Domain B, I didn’t want to unbind but I did want the new LDAP server to be the primary authentication source.
Using my previous OpenLDAP binding script as a starting point, I was able to build a script to handle moving our Macs without downtime or account changes. See below the jump for details.
In Mac OS X Server 10.7.x and 10.8.x, there’s been an issue that Mac admins have run into more than once:
Profile Manager in 10.7.x and 10.8.x also has an known issue where it crashes when set up in a VM. The root cause is the same: Profile Manager needs to have Open Directory running and Open Directory won’t turn on.
The fix for this issue in 10.7.x Server and 10.8.x Server is simple – give your VM more than one processor. Once you give the VM multiple processors (two is fine), Open Directory should begin working. This will also fix the Profile Manager crashing issue, as Open Directory should now enable properly.
In Mavericks, it appears Apple has addressed this issue. In my testing, Open Directory no longer requires multiple processors.
Now that Open Directory can run with one processor, Profile Manager also now runs properly on a one-processor VM.
In my travels, an issue I’ve occasionally dealt with has been moving Macs between directory services. In some cases, this meant between AD domains. In others, moving a Mac from an AD domain to an OpenLDAP server. In each case, as part of the process, the UID of the user’s account changed from the UID associated with the old directory service to the UID associated with the new directory service.
File and folder ownership on OS X is associated with UIDs, so files and folders that were created and saved by the old account may now be either inaccessible or read-only. You can update the ownership by using the Unix find command to locate files and folders owned by the old account’s UID and change the permissions so that the file or folder is now owned by the new account. For details, see below the jump.
Apple has released Xcode 5.0.2 through the Mac App Store for all Macs running 10.8.4 and higher. While the command line tools for Mavericks are now included with Xcode, the command line tools for Mountain Lion can be installed separately through the Xcode preferences, in the Downloads section.
For my users who are developers, Xcode is part of their their new machine builds. I wanted to include Xcode 5.0.2 and also, where appropriate, install the command line tools automatically without needing to enter an Apple ID. With a little help from the Mac App Store, I was able to do this using Packages. See below the jump for the details.
Thanks to Allister, I ran across this NetSUS-related feature request at JAMF Nation. While the feature request makes sense in the context of the requester’s shop, it is possible to resize the NetSUS appliance to give it additional space.
The steps should be reasonably similar for each virtualization solution, but see below the jump for how to do this with VMware Fusion 6.x.