Hi Zach. You're new to Jamf and I'm assuming to Mac management as well. The concepts are similar to SCCM, but the workflow and terms will be different. Those articles aren't entirely useless, if you know what you're looking at.
Based on the information given, the "install.xml" file contains instructions that are customized for your environment. It also discussed how to build the package in Composer. I will concede that the screenshots are showing you the least important parts.
Where are you having trouble?
@bradchapman Once I have the package built, and I write the script (everything is done verbatim per the articles) it fails. This is what the log shows-

After going through some of the JAMF forums regarding the issue, I tried editing the script and file location based on some of the recommendations, but to no avail.
On top of this, it seems that some are using different software entirely to do this, as this forum thread outlines. But you're right, I'm new to the backend of this, and trying to learn as I go, so the patience and advice is much appreciated.
Looks like the script is missing the '-target'
Should be: installer -pkg /Users/Shared/antivirus_for_mac.pkg -target /
I confirmed I had the script typed out correctly, and I do. I still got the same response on my test machine. One thing I am now noticing is that the package in JAMF is actually "pending" but I created it days ago. I haven't had any of my other packages pend like this, so I'm assuming that something is going wrong with what I'm doing in Composer?

Please post a screenshot of the package source in Composer that you made for the Bitdefender package. Open all the folders so we can see where you put the antivirus_for_mac.pkg package.
Example: here is a package I built for deploying CrashPlan:

Technically the penultimate instruction is unclear. There is no way to add "files and processes" from the Scripts payload. What I think they're trying to get you to do is just use the Files & Processes payload to execute the command: installer -pkg ...
. It isn't strictly necessary to write a separate Script. But I digress... please post the Composer window and let's see what's happening.
I've been deploying Bitdefender succesfully with the first link to the Bitdefender website you mentioned in your starting post.
It was a bit unclear to me at some stages.
But here's what you need to achieve:
You need to create a package that will copy the .pkg to /Users/Shared and then I execute this line in a script (I use the Shared folder for multiple apps, so I copiy it in a folder Bitdefender:
/usr/sbin/installer -pkg "/Users/Shared/Bitdefender/antivirus_for_mac.pkg" -target /
Also i remove the link to the uninstaller:
rm -rf "/Applications/Bitdefender"
I don't understand why you need a script at all. Why not upload the package to the storage server(s) and just use a policy that uses that package with the 'Action' "Install" to the clients that have the needed kernel extension whitelisted?
Here is a screenshot from Composer on my end.

Aha! You put everything inside a folder called Bitdefender_for_MAC
, inside /Users/Shared
.
Your install command was missing the complete path. The fix is very simple:
installer -target / -pkg /Users/Shared/Bitdefender_for_MAC/antivirus_for_mac.pkg
There's a couple of "good housekeeping" habits you may want to start developing now:
- Put the installation files in a different location that isn't easily found.
- Clean up after yourself by deleting install packages after deployment.
For #1 the /Users/Shared
folder is not hidden by Finder, but a place like /var/tmp
is hidden by default.
For #2, you'll use variations of the rm
command, but this can be dangerous if used incorrectly. Example: rm -rf /var/tmp/Bitdefender_for_MAC
Perfect, I adjusted my script to support this. Another issue I am noticing, is that when I am uploading the package to JSS, what files should I be selecting for the FileName and Manifest? I've been selecting the .pkg, but when I do so, it doesn't seem to populate correctly. This is what I see directly after adding the package. The name was Bitdefender_for_MAC.pkg, but now it nulls out and calls itself 'Package.'
I'm assuming this is from the way I am uploading it?

I was just able to test everything, and I am getting the same error log.
@zachbuzalski : based on your previous response, if you get the same error it means the package wasn't downloaded to the computer during policy execution. I assume you're uploading packages via the Jamf console to a cloud distribution point? Try deleting the package object in Jamf, and uploading it again.
Policies always refer to packages as objects, and not by the filenames directly. That's because packages—like so many other objects in Jamf—have additional metadata like title, priority, category, exclusions, etc. Thus, deleting a "package" from Jamf actually deletes the file from the distribution point AND the entire object, which makes it disappear from all policies that were using it. Uploading the same package creates a new package object with its own unique ID, and that new package object has to be added back to those policies.
Just wondering ... if your company 'just uacquired] Jamf,' does that mean you 'inherited' the Jamf environment, or was this a new installation? Do you know if anyone at your organization got this brief training called a "Jump Start" or are you planning to do so?
This is a new installation, and I am the only one working on it. To answer your initial question, yes. I am uploading packages via Jamf console. I will try deleting it and re-add it, and will update you.
Is there any other information or screenshots I can provide that would be useful?
@mschroder
It needs the XML, so you cannot just run it as an standard PKG.
Then it skips the license and setup information
OK, I see. What I usually do in such cases is install the XML via a script triggered by policy X, and have the same script trigger the policy Y that just installs the package. That way the it is assured that the XML is already existing, but I don't have to worry about fetching the package, installing it via the install command and cleanup afterwards. In my case (almost entirely BYOD) policy X would be available in the Self-Service, but policy Y would only have the custom trigger and not be available in the Self-Service.