[Tim Sutton]

[QUOTE][u]Quote by: yoshi[/u][p]modified installer here:

[url]http://dl.dropbox.com/u/6496412/Office_2011_14.2.1_Update.dmg[/url][/p][/QUOTE]

Would you share what you did to modify the installer? I’ve posted previously in this thread regarding the issues I ran into with patching the post-14.1.0 updaters. It seemed to work, but only by disabling an aspect of Microsoft’s package selection logic to a point that I wasn’t comfortable using that in my base image.

Given their evolving history of poorly-written installer script logic with Office 2011 updates, I’d tread with caution in doing any further patching soley for the purpose of having an up-to-date version baked into an image.

[Tim Sutton]

I’d encourage anyone to file a bug if this is important to them. I copied mine to openradar:

http://openradar.appspot.com/radar?id=1484401

[Tim Sutton]

Same issue. I’ve tried setting guest via a 10.6 OD master, via a local MCX guest record and via a en0-identified local_desktop record in a separate /Local/MCX node.

We won’t have the recovery partition for labs but probably will for a number of office desktops. I’ve just tried enabling FileVault on my test machine that does have the partition, but it doesn’t seem to have any effect.

Although the guest login options are still present in WGM, I can’t find any such functionality in Profile Manager.

Is anyone filing bugs on this? I’m not successful with the latest 10.7.3 seed either. I’ve just posted these findings to the MacE thread linked earlier.

[Tim Sutton]

[QUOTE][u]Quote by: freepms[/u][p]I dropped the SP1 Installer on that patcher, then checked the postflight. The $3’s have not been added nor the launchctl load line commented out.[/p][/QUOTE]

I’m not sure a working SP1 installer patcher was ever posted. MS changed their naming convention slightly for their component packages, so it must be modified. If you look at the script used by the original 14.0.0 installer patcher, and compare the two installers, you can see the difference in what needs to be modified.

Remember, the patcher for the installer isn’t the same as the patcher for updates.

[Tim Sutton]

[QUOTE][u]Quote by: Goldberg[/u][p]I got the 14.1.3 Updater working in InstaDMG. I used the Patch Office scripts found in the post. I tried several different combos of the patch and I’m not sure which combo worked. I posted my working 14.1.3 to my dropbox with the understanding that it won’t be up there forever.

http://dl.dropbox.com/u/10274536/InstaDMG%20Office%202011%2014.1.3%20Update.zip

Good luck,

Goldberg[/p][/QUOTE]

Yes, quite a while back I posted a patcher that “works” for the updates past 14.1.0 in InstaDMG. The problem is, it works by simply disabling the command to check whether a component should be installed, and so *every* component will have its installer run. This means if you have an install without, for example, Outlook, running this patched updater will try to install Outlook, and you’ll have a half-functioning copy of Outlook when you probably didn’t want one at all. If you have only a default Office install in your environment, it may work OK, but there might still be some components that weren’t installed by default in the original.

I moved away from bothering with the updates past SP1 and just left Munki for updating this. I assume at some point there will be an installer available with SP2 rolled in, we may or may not have the same issue patching it, and this process will repeat.

[Tim Sutton]

Sure, he’s not completely stuck but he’s only left the option of manually downloading updates in a browser, checksumming each one, appending the sha1 to the dmg and placing them in the InstaUp2DateCaches folder. Doable, but he can’t even see what the correct naming format would be.

Yanking the system proxy’s an option. If there’s a native framework available via PyObjC, Karl will certainly endorse that method above others. I recently had to parse system_profiler in a python script and it’s doable, but ugly. system_profiler outputs XML as an option, but it’s only designed for use by System Profiler.app. If you ever look at it, you’ll see it bears little resemblance to a logical structure. Going the system_profiler route, you’re stuck with parsing text subject to change, though by XML you’re using its internal key names, so safer than parsing the text output. Again, doable.

The simplest option, of course, is to provide a command-line option to instaUp2Date.py to specify the proxy. On a related note, I think there’s actually quite a few “advanced” options for instadmg.bash that’d be very handy to have available to pass with the –process flag.

[Tim Sutton]

To second that, my current build hardware is a spare 2009 Mini server with internal drives in RAID0, and a FW800 disk for scratch.

I’d love to have something faster, but it’s what I’ve got and it works fine.

[Tim Sutton]

This issue has been given a full analysis already on the Developer Forums. Discussing it anywhere else is a violation of the NDA.

[Tim Sutton]

[QUOTE][u]Quote by: bw38[/u][p]I think the issue is that you’re trying to use the gray restore disk which you’re not supposed to be using. Doesn’t mean it won’t work, but it’s not recommended. You need to use a retail disc or a reference disc. The latest reference disc is 10.6.3 that I know of. Now in theory, I suppose a 10.6.6 disc should work if you apply 10.6.8 combo update. Is the machine you’re running up to date with the latest combo update? Try applying the combo update, not the delta.

Also try to download r423. Seems it came out just today.[/p][/QUOTE]

Using grey discs is fully supported, for when you need to build your image for new hardware models whose drivers have not yet been included in the mainstream OS builds. Freely-available presentations have been given on how to do this, as have numerous forum posts you can find here. Of course, one mustn’t use these discs for general images, but running importDisc.py on a grey disc will parse the appropriate version and build no. just lie it would for a retail disc.

The issue is the most common one faced by new users. I find that with using a dedicated build machine, I run into this issue very rarely.

[Tim Sutton]

I wrote the latter – but as I mentioned on the instadmg-dev forum, this patcher will try to apply every single .pkg within the 14.1.0 updater mpkg, because it patches every pkg installer to bypass its “should I be installed” check. I’ve not checked 14.1.2, but it seems that it worked for you?

On a standard install with all the default components, I haven’t seen any issues, but I can’t necessarily test all the components that may depend on some support libraries that may or may not have been installed with the original application(s).

And, it certainly will leave a half-functioning install of any additional components that weren’t installed with the original installer. For example, for labs I omit Outlook using InstallerChoices. Applying this patched update on top of such an installation will install an unusable Outlook (functioning, but with missing resources).

I know Microsoft has released an SP1 installer disc, but I haven’t yet heard anything conclusive about whether this works easily with InstaDMG. For now I leave my base image with 14.0.2 and let Munki do the rest, but if I could at least get SP1 installed in the image with confidence, that’d be nice. Anyone with feedback on this?

[Tim Sutton]

[QUOTE][u]Quote by: Allister[/u][p]Hey Chris,

I have a post about this on the mailing list, the line you have for your catalog file would maybe work on a mpkg file, but cygnus2112 reports that the old way still works. That is, if you make a new dmg with your ChoiceChanges file at the root next to the mpkg that should work. Two other alternatives: you could modify the distribution.dist file, which I haven’t tried, or you could do what I do, which is rip the thing apart into a catalog like this:
[url]http://pastie.textmate.org/private/mquert7rzz4fpnwqxwzdw[/url]
You’ll notice I comment out the pkg that forces you to quit any browsers while it installs, and I also leave out silverlight since I don’t have any sharepoint services running anywhere. I wish it was easier, I’ll be moving to either repackaging or having munki doing these installs on firstboot soon, if I can’t get this installerChoices bug fixed. Thanks,

Allister[/p][/QUOTE]

Also, doing it the old way with a choices file at the root of the .dmg containing the package, instadmg.bash expects the choices file to be named “InstallerChoices.xml.” instaDMG will take an alternate choices name for the BaseOS, but not for individual package items. This is strictly instaDMG functionality.

Recently, the functionality of adding a choices XML as a fourth tab-stop-item in an instaUp2Date catalog was added, but I personally haven’t used this method. Since instadmg.bash is hardcoded to expect InstallerChoices.xml, I can only assume instaUp2Date writes out this file to where instaDMG expects it may find it.

[Tim Sutton]

[QUOTE][u]Quote by: Allister[/u][p]The InstaDMG guide suggests using separate drives for image creation to improve performance (i.e. one for reading the disk images and packages, one for the temp files and the output images). If I have am using a dedicated Mac mini (2009 server running 10.6 client) and an external FireWire 800 drive, what is going to give me the best performance? Drive to drive within the mini? Internal to FW 800 external? Internal RAID 0 to FW 800 External RAID 0? Forget the whole thing and just load up the internal drive bays of the Mac Pro (2006) that I use as my personal machine and have it work in the background?

Experiences? Opinions?[/p][/QUOTE]

I have this exact setup, and after testing a few permutations of scratch and main disks, I found the fastest configuration to be to run the system off RAID 0, and use a fast FW800 drive for scratch. On small images you might get close or slightly faster the other way around, but because you’ll have the ASR scan for restore happen at the end on the system disk, the RAID 0 helps a lot here.

Crossing my fingers that I won’t have to be self-servicing my Mini’s hard drives any time soon, but at least the 2009 models give a bit more elbow room when the time comes.

[Tim Sutton]

I guess I’m not following. Either your SUS downloads an update once or instaUp2Date downloads an update once, or both. To save time maintaining images, point the newly-imaged machine to your SUS and/or Munki repo. To save time on reimaging, keep your .catalogs up to date.

I iterate build tests on a daily-to-weekly basis, and there are no download time issues because no scenario involves downloading an update from Apple more than once, except for that in which I bootstrap a new machine as my next build station, which is rare. If download time savings were crucial I could even copy the cache to the next build machine to avoid another download from Apple.

If you’re wondering about the possibility of building the updates into the caches BaseOS install (and I did at first), it isn’t possible. But as even the smallest update can affect core components, I think it’s a healthy level of paranoia, and you can always be guaranteed that your cache is an installed system from a specific disc with specific installer choices, independent of whatever sets of updates you may be testing.

To improve on speed, a couple hundred $$ on several fast cheap drives in RAID 0 will go a long way.

[Tim Sutton]

[QUOTE][u]Quote by: themacdweeb[/u][p]actually, as combo updaters are now regularly over 1GB in file size, any savings of time would help. just my two cents.[/p][/QUOTE]

Sure. But since it has to be downloaded at least once, for most people the instaUp2Date cache folder will take care of never having to download it again. If you’re constantly building on fresh machines, then you can copy the cached dmgs to your internal web server. Having the checksum placed automatically in the filename may be helpful, as a check for the occasional time when Apple decides to update the distrubution file wihout incrementing the version number.

[Tim Sutton]

[QUOTE][u]Quote by: themacdweeb[/u][p]Thanks, gents:

@ allister: we use casper, we have scripts that point to our hosted SuS, but that wasn’t the point of my post. i’m trying to reduce the amount of time instaDMG takes to run its process and create a baseOS image. i thought that instead of reading a catalog and then downloading each file and update from apple’s servers that we might, instead, point it to our internal SuS to help save download/processing time for instaDMG.

d[/p][/QUOTE]

You’re free to download and host the Apple support downloads internally, if the bandwidth savings are crucial, but since instaUp2Date will cache your checksummed downloads, it’s rare that you would download an update more than a couple of times. Unless you’re building on a cluster of machines, the next time your instaUp2Date cache is empty is probably the time when all of the typical updates have been incremented at least once.

[Author]

Posts