Replication doesn't seem to be handling Scripts folder or issue with scripts?

[donmontalvo]

For some reason a policy we are running is failing because a script doesn't appear to be present to JSS (it's there; it's executible):

/usr/sbin/jamf is version 8.62 Executing Policy DM_set_HostName_using_ComputerName... Creating directory structure for /Library/Application Support/JAMF/Downloads/ Downloading http://server.domain.com:80/CasperShare/Scripts/xx-set-hostname.sh... Error running script: The script could not be found on the server..

I constantly have to mkdir the Scripts folder and scp all the scripts, then to be safe I have to chown and chmod the scripts.

I only noticed this recently when I went to check if our hostname setting script was working...the red error entries in the Logs page for this policy all point to one server (a replica). Any idea what might be causing replication to complete without the Scripts folder being replicated?

TIA

Don

[kitzy · Accepted solution]

In that case, I'd double check permissions on the scripts folder in your master distribution point.

[kitzy]

Have you checked the permissions on the scripts folder on the replica? We had a similar issue a while back and I recall the permissions not being propagated properly being the cause.

[donmontalvo]

@johnkitzmiller One of the Distribution Points didn't have the folder, even though replication using Casper Admin completed without any errors. I'll upload a test script and try replicating again to see if the problem goes away.

I can't wait for v9 to be released...hopefully these issues will go away. :)

Have a good weekend!
Don

[kitzy · Accepted solution]

In that case, I'd double check permissions on the scripts folder in your master distribution point.

[donmontalvo]

@johnkitzmiller Thanks John, I put this on my gotta-do list for after Thanksgiving. :)

Gobble, gobble!

Don

[andrew_stenehje]

We've been having similar problems with a few Windows Distribution Points at a few sites. We get the same error message you get (script could not be found) with a script that runs on logout... but only on a handful of mostly 10.6 machines. These same machines seem to fail repeatedly, while most of the machines at these sites run the script normally from the same DP. The script exists on the DP and has the correct permissions/ownership. Same thing with some packages... and they install fine from the command line (using jamf policy -trigger or -id) or from Casper Remote.

[jarednichols · Accepted solution]

Gents-

If you're on IIS, check your MIME types. If you don't have them defined correctly, clients get 404 errors which will throw you totally down the wrong trail. Found that out the hard way.

Also, if you're using robocopy, make sure you're excluding your web.config file. Found that out the hard way too.

[donmontalvo]

@jarednichols We reverted back to AFP for Distribution Points because of the AAMEE pacakges issue. Once that problem is fixed, we'll toggle on the SMB shares on again. Good to know about those issues though, keeping notes for the day when we are able to move back over.

[jarednichols]

In my mind, there's no way a package shouldn't transfer properly. Because I'm unfamiliar, are the AAMEE packages pkgs or dmgs? (I assume pkg)

What's your MIME type for pkg? I've got them defined as application/octet-stream

[donmontalvo]

@jarednichols We force AFP for all Adobe package (AAMEE) deployments. We use the native PKG format that AAMEE spits out. For a while we used DMG and a script, but doesn't work at imaging time. So we dropped SMB and are back to AFP for now...until Jody can get his engineers to "fix" the PKG issues that prevent us from using SMB.

[tkimpton]

@donmontalvo

I found that the propagation of permissions causing permissions, net app filer not supporting http download requests and my admin account not having permissions to the net app replica share to be the main problem.

Because of damn Adobe AAMEE created pkgs I haven't bothered sorting the issues out with the smb share. Instead I'm just using afp and replicating to the smb share for backup purposes only.

[donmontalvo]

@tkimpton When we were testing the SMB issue, we found that the AAMEE PKG installers were "breaking" when put on SMB shares. I read somewhere it has something to do with broken aliases within the PKG? Have you tested the PKGs that are replacated to SMB, like double-click in Finder?

[jarednichols]

@Don

Interesting that they're using aliases within the PKG. I'd have to look it up on the developer pages, but I'm fairly certain that's a total no-no as far as Apple is concerned. For something that's supposed to make their product more Enterprise friendly, it's ironic that this is holding it back.