Deploying OS X: Package Deployment & Network Boot Issues

Here is some interesting information I've come across at great pains and searching.

When deploying Mac's, and therefore needing a customized image of sorts to do so, it would appear that a NetRestore has proven to be much more beneficial and generally all around easier than a NetInstall.

I created a NetRestore image with System Image Utility (SIU) on a Mac running Mac Server by using the OS X install file from the AppStore.  Once defining that as my source for the image, I opted for creating "NetRestore" rather than NetInstall once continuing within the utility.  This allows for creation of a local admin, and post-installs packages without fail once the image passes creation, as well as other customizable features that are otherwise not applicable to NetInstall.

For example (although this data is old), the below chart from an Apple Deployment Guide (Apple Training Series Mac OS X Deployment v10.6: A Guide to Deploying and Maintaining Mac OS X and Mac OS X Software)
It indicates that some of the Automator workflow actions simply are not compatible or applicable with some of the methods of network installs.

Anywho, here are a couple of things that helped me tremendously.

First off, our Macs we were testing were on an isolated network switch.  Although the switch appeared to be configured correctly, and the DHCP and DNS and everything was set on the Mac Server, the clients would NOT perform a network boot (either holding down option key upon startup or holding down N key), although at times they could see the images in the Startup Disk within the OS X or Recovery Mode.  Long story short -  if network images in the /Library/NetBoot/NetBootSP0 folder are not showing up as startup disks on client Macs, make sure spanning-tree portfast is enabled on your switch interfaces!  I also found it helpful to not have them in the default vlan 1 but create a new one with an associated vlan interface.  See this link
https://discussions.apple.com/thread/1815801?tstart=0 down in the resource section below for more info.

Second, packages were a pain, and trying to figure out why some of them would or would not add to the workflow.

Here are a few tricks I found:

To create a package (.pkg) from a .dmg so you can add the desired app to the workflow, do this...

1) Mount the .dmg (can double click or do in Terminal) to make it an attached volume.  Note the name of the volume and the .app within.

2) In terminal, type: sudo pkgbuild --install-location /Applications --component "/Volumes/<volume name>/<appname.app>" "./Desktop/<desiredname.pkg>"

3) Authenticate the sudo

This will create a pkg from an .app within a .dmg, on your desktop.

Now, to fix packages for deployment within the Automator workflow, the below may also need to be done to make it deployable:

In terminal type: productbuild --package "./Desktop/<appname.pkg>" "./Desktop/<newnameforpackage.pkg>"

This will create a deployable .pkg on your desktop, from the one created in the other steps just above.


Now, I do recommend, as I've found this helpful - when using System Image Utility for creating images, just before saving and creating the image click "Customize" to open Automator.  Then go to File and Save the workflow or else you may not be able to look back at what was in the image in case you forget when testing/creating multiples.

Sources/Resources:

https://discussions.apple.com/thread/1815801?tstart=0

http://www.techrepublic.com/article/pro-tip-use-terminal-to-create-packages-for-software-deployment/

http://apple.stackexchange.com/questions/167522/packagemaker-alternative

https://github.com/munki/createOSXinstallPkg#further-note-on-additional-packages-and-yosemite

http://stackoverflow.com/questions/11487596/making-os-x-installer-packages-like-a-pro-xcode-developer-id-ready-pkg

https://youtu.be/CIEuUAmvjwQ

FIX: Outlook 2013/2016 - Email Address No Longer Valid

**Update thanks to anonymous commentor, this apparently works for Outlook 2016 also**


One of our users was getting an undeliverable message error in Outlook 2013 warning that one of the recipient's email addresses was "no longer valid" when sending mail to another particular user within the company.

The recipient was able to still receive the emails regardless, and the sender did not receive the error in the Outlook Web App.

This lead me to believe it was something local to the Outlook client, particularly related to the Autocomplete.

Tried removing the recipients address from the Autocomplete list to no avail.

After some research, tried this and it worked.

For Windows 7:

Turn off Outlook.

Open widows explorer and turn on "show hidden files"

Go to C:\Users\**USER**\AppData\Local\Microsoft\Outlook\Offline Address Books

and re-name the f[older] here (add "old" to the end).

Restart Outlook.

The user was then able to send mail to the recipient without the warning message.  We re-downloaded the Global Address Book and they were still able to send mail to the other user without error.

Source:

https://community.spiceworks.com/topic/397609-weird-email-issue-e-mail-address-is-no-longer-valid-using-office365?page=2