ASR encountered a problem (UNCLASSIFIED)

problem. See Jamf.log for details. Reverting to installation using
ditto...

What are things that typically cause this? I read the KB article on
jamf's site, but when I did a scan in Disk Utility no problems were
found. I'm also not receiving this error every time, but I'm seeing it
at an increasing rate.

Thanks
Allen

Dave

This isn't during imaging time. I'm seeing this when Snapshotted Apps are installed from Self Service or Remote.

Thanks
Allen

We see the same when installing our office 2011 snapshot.

Our os installs are modular.

But it's the only dmg we see it with & as it's v14.0 I'll soon be rebuilding the dmg to 14.0.2 as the updates have really resolved some issues for us.

I'll try to remember to report back & advise if the recreated dmg resolves this issue.

Regards,

Ben Toms

Ben,

This is exactly what I'm seeing. I created a new Snapshot DMG with 14.0.2 and I'm still seeing the same error. I checked the jamf.log on the target machine and it says something about one of the automator items not being a directory (I'll double-check tomorrow)? The funny thing is it doesn't happen every time.

Thanks
Allen

Good ol' office for mac.

Always causing issues!

Any idea which automator action is missing?

Regards,

Ben Toms

I'll have to check tomorrow, I don't remember off the top of my head. I don't see any issues with my image that contains Office 2011, this is only when using Self Service or Remote. Till I can narrow down this issue I switched the Self Service policy to install Office from the mpkg and then install the 14.0.2 updater & communicator 13.1 updater. We push Office 2011 MCX, so I'm not snapshotting any preferences.

Thanks
Allen

Thanks.

We've only snapshotted the office 2011 install as it's quicker.

Our os image is modular, is your os a monolithic image?

Regards,

Ben Toms

My image is modular. I use InstaDMG to create my OS image, then create a few compiled configurations with Symantec Endpoint, Office and a few first run scripts. The rest gets installed by the user via Self Service (well it will once that is fully deployed). I just created a new config on Friday that includes Office 2011 (snapshot version). I didn't see any errors during the compiling but I will double check that as well, is there a log file for the compiling process?

Thanks
Allen

Here is the error I'm seeing in the jamf.log when the ASR error occurs. Not sure what is happening, but main.nib should not be a directory.

Allen

Tue Feb 1 14:31:08 jamf[68422]: Executing Policy Office 2011...
Tue Feb 1 14:31:10 jamf[68422]: Running Script officeRemovalPre.sh...
Tue Feb 1 14:31:21 jamf[68422]: Installing Office2011_14.0.2.dmg...
Tue Feb 1 14:35:39 jamf[68422]: ASR Error while installing Office2011_14.0.2.dmg: XSTA start 153 client
XSTA setup
Validating target...done
XSTA metadata
Validating source...done
Validating sizes...done
Copying PINF 2 100 Copy
PINF 4 100 Copy
PINF 6 100 Copy
PINF 8 100 Copy
PINF 10 100 Copy
PINF 12 100 Copy
PINF 14 100 Copy
PINF 16 100 Copy
PINF 18 100 Copy
PINF 20 100 Copy
PINF 22 100 Copy
PINF 24 100 Copy
PINF 26 100 Copy
PINF 28 100 Copy
PINF 30 100 Copy
PINF 32 100 Copy
PINF 34 100 Copy
PINF 36 100 Copy
PINF 38 100 Copy
PINF 40 100 Copy
PINF 42 100 Copy
PINF 44 100 Copy
PINF 46 100 Copy
PINF 48 100 Copy
PINF 50 100 Copy
PINF 52 100 Copy
PINF 54 100 Copy
PINF 56 100 Copy
PINF 58 100 Copy
PINF 60 100 Copy
PINF 62 100 Copy
PINF 64 100 Copy
PINF 66 100 Copy
PINF 68 100 Copy
PINF 70 100 Copy
PINF 72 100 Copy
PINF 74 100 Copy
PINF 76 100 Copy
PINF 78 100 Copy
PINF 80 100 Copy

could not copy //Library/Automator/Add Content to Word Documents.action/Contents/Resources/en.lproj/main.nib; Is a directory
Bom copy exited with error 21
Could not restore - Is a directory
XSTA fail

I'm having this exact same error. Has anyone figured out what's
causing it, or how to work around this problem? I'm trying to roll out
Office 2011 and this has thrown a wrench in the plans.

What's unusual is that it doesn't actually appear to "undo" the
install as it claims to. Even though it claims to be reverting using
ditto, when it finishes, the Office 2011 install is there and
(mostly?) functional. Apps launch and work. I haven't tested all the
Automater actions.

Any ideas? Thanks,

- Damien.

It is an error, but it is not a problem. Ditto performs the transfer that ASR failed to do.
Still, it would be nice if ASR didn't fail on that package (I've seen it too, but I don't remember for sure whether it was that package), as ASR provides Casper with progress information that ditto doesn't provide.

My guess is that something is wrong with the way it is generating the metadata within the disk image. My DMG contains that item, and it is a regular file. It is also a regular file in the resulting install.

I see the same error with my office 2011 snapshot.

Was yours a snapshot or from composers pre-installed diff?

Regards,

Ben Toms

I used Composer's "diff".

Bugger.

Maybe something funky with office then?

Regards,

Ben Toms

I can't get into the machine that had the error right now, but I remember seeing the automator files weren't showing up properly when I LS'd them. Instead of drwxrwxr-x they showed up as -rwxrwxr-x, from what I remember.

I haven't tried this yet, but would it be a worth caching the dmg to a machine and then do a cache install?

Thanks
Allen

Just take a Snapshot of what was installed via the pkg, index it and then check allow this package to be deleted. You should then be able to uninstall via a policy?

Has anyone tried doing a cache install of the dmg to see if asr fails?

Allen

FWIW, I've done some more testing on this. I was having this ASR
reverting to ditto problem with both my iLife 11 and Office 2011
installs. Both were made with Composer 7.2.1. I tried indexing the
images and also used Disk Utility on the JSS itself to "Scan Image for
Restore". Neither helped.

Ben Urban is correct. The install completes but by using ditto instead
of ASR. My problem with this is that it almost doubles the time for
installation of these large software packages.

What finally worked for me and made the errors stop was to build the
diff as a .pkg instead of a .dmg. Yes, I know that this prevents me
from being able to uninstall these softwares later on via a policy,
but that's not a concern for me. I need these installs to work without
the users seeing errors when they execute from Self Service.

Next up is a policy to cache these large .pkgs on users machines so
the install "goes faster."

- Damien.