Casper imaging vs Deploy Studio

[BOBW]

Hi All,

Just wondering what everyone is currently using, Deploy Studio or Casper tools to image their Macs.

Just about to make a decision on Casper suite and one of the things we are currently using is Deploy Studio. Am I going to lose functionality by going with Casper to image? Should I stick with Deploy Studio and use Casper for management only?
Is there any features I get with Casper that I don't get with DS?

Thanks

[rcorbin]

We use Casper Imaging via mostly Netboot. Works great.

[Look]

We use Deploy Studio without any real issues. We have looked at both and keep deciding to stick with DS, Ideally we will just move straigh to a thin / policy based deployment when we do change.
Probably the biggest difference between the two is DS requires you to compile images out of Casper Admin and then copy them across to the DS server as monolithics. Casper Imaging can do package based deployment based on the configurations without having to be compiled (although it's faster if you do), this means images can have individual packages updated and theses are imediately available to to the imaging process.
Personally I don't really like the Casper Imaging client, familiarity of the DS system for me allows very customised complex single touch workflows which can be nice in certain situations.

[mm2270]

FWIW, we use DeployStudio along with Casper Suite for management and don't have any real issues with this. You just will need to make sure you include a QuickAdd.pkg or some other method of making sure the Macs that are imaged with DS get enrolled in your JSS.
I still think DeployStudio has some flexibility that Casper Imaging lacks, especially in regard to the overall workflow. You can make DS operate almost any way you want. Casper Imaging's 'image' workflow is a little more rigid. Also, DS feels to me is still a little better for complete offline or self contained imaging than Casper Imaging is, although there isn't a huge difference these days between them in that regard.

OTOH, there are a few items you will not be able to take advantage of if you stick with DeployStudio. For example, no Pre-Stage imaging. Not sure if that would constitute a deal breaker or not. When I've used Pre-Stage, its been pretty cool, but we have no use for it where I am now. Also, I don't think you'll be able to use Auto Run data as effectively. If, for example, you want to re-image a lab environment on a regular basis and just have the entire thing automated, Casper Imaging is still better than DS in this regard.

Each has its advantages and disadvantages, so unless one can do something that the other simply can't which is very important to you, it may come down to personal preference.
Anyway, why be forced into a decision right away? Stick with DeployStudio to start if you feel comfortable with it, and explore Casper Imaging at your leisure, making sure you fully understand how it work, and if/when you feel you can switch, do it when you're ready.

[qsodji]

We use Deploystudio, and I have been pretty happy with it. I have even incorporated App deployment from Casper into it as a workflow.
Once the mac is imaged and enrolled into casper via Quickadd, there is a workflow that fires up a policy from Casper (via id or custom trigger) scoped to recently added computers to Casper.
This basically allows me to only have to update packages in one place and ensure it still happens at imaging.
It has been working really well and our process is down to about a few minutes per machine.
By having the policy scope to only new added computers and having no automatic triggers, I can ensure it doesn't go off on other computers even if they fell into the scope.

[bentoms]

@c0up3 I use Casper Imaging, my workflow is detailed heret

[Chris_Hafner]

It's completely up to you so long as you accept the caveats. You can also shift slowly form DS to CI if you feel the need. Personally, I prefer Casper Imaging and we used to be a DeployStudio shop. We ARE heavy pre-stage users and tend to really take advantage of some of the unique features of Casper Imaging in this regard. It's also very important to us to have a high speed deployment strategy that's just not served well by DS in our environment.

P.S. Auto Run Data will be COMPLETELY functional if you use DS. When the unit is first enrolled using the quick add package that data will be stored. Any policy that's added after can be applied to their AutoRun Data.

[mm2270]

@Chris_Hafner Regarding AutoRun, while I'm aware Casper can still add any applications installed or stuff run to a Mac's AutoRun data, what I was referring to above was, I'm not aware if its possible to then use that data to automatically re-image a lab and take advantage of it. Maybe it is, and I'm just not aware of how since I've only briefly looked at AutoRun in all the years I've been using Casper Suite now. I've never had a need to truly use it, so I'm admittedly a bit green with it.
Would DS be able to re-image lab Macs and set them back to a previous state by using the AutoRun data stored in Casper? If so, that's cool, but I was not aware it could. I thought that was strictly a Casper Imaging function.

[rtrouton]

I've been using DeployStudio and Casper side-by-side for a few years now and there's been no issues with the two co-existing. DeployStudio handles Casper's install by installing a QuickAdd installer package.

[Chris_Hafner]

@mm2270 Ahh... I wasn't thinking in that direction. i.e. DS using Casper's AutoRun Data. Honestly I have no idea except that the data is available from the JSS via API. I was commenting on the AutoRun Data being properly collected by the JSS and being available from that point onward. Oddly, I really should have thought about it but alas... In any event, I doubt it as well.

[davidacland]

@mm2270 I've been using AutoRun a lot more recently. When we're adding Casper to an existing site, we quick add all the devices first, usually with ARD or Recon, then set the relevant AutoRun settings, and lastly create a sequence of policies set to activate in 4-6 hour intervals to netboot 10-15 Macs at a time.

[mm2270]

Hi @davidacland Thanks for the info. That makes sense, but are you referring to booting into a Casper Imaging imaging workflow, or a DeployStudio imaging one? My question was around whether DS has any ability to utilize the AutoRun data stored for a record in the JSS, and I think the answer is no. Since DeployStudio isn't aware of and can't access the JSS directly to read any data from it, I would suspect this is impossible, at least not without some fancy API scripting maybe. I think that workflow is restricted to Casper Imaging only.

As I mentioned, we don't use AutoRun here and don't have a need for it, so I'm only asking so I can speak accurately about it if the topic comes up.

[davidacland]

Ah ok, I was just talking about Casper Imaging.

It certainly would be possible with DS as you can run scripts as workflow steps. A script could read the autorun data via the API and then use installer to run the relevant packages.

Would be a lot of work though.

[msnowdon]

@rtrouton

I've been using DeployStudio and Casper side-by-side for a few years now and there's been no issues with the two co-existing. DeployStudio handles Casper's install by installing a QuickAdd installer package.

Like you, Ive been using Deploy Studio & Casper for the last couple of years. I wanted to get fancy and have Deploy Studio image, bind to AD, install Office & Adobe Reader and enroll in Casper.

Everything works except for the enrollment. I copied a quickadd.pkg to the DS Repository "packages" and included it in the workflow as the last item. Everything works but it cant enroll. It will reboot a few times and give up.

Not sure what I'm doing wrong.

Thanks

Mark

[davidacland]

@msnowdon there shouldn't be any issues with that method. Are you setting the quickadd as a postponed install? Does the quickadd package work normally?

The only other possibility I can think of is JSS reachability while the quickadd is trying to run.

[msnowdon]

I think that it cant contact the JSS when its trying to run. Not sure why though.

[rtrouton]

@msnowdon,

How are you generating the QuickAdd package? The reason I'm asking is that the QuickAdd that gets downloaded from the JSS's enrollment site has a one-time enrollment invitation, which is specifically for the machine which accessed the enrollment site. If you take it to another machine, it won't work to enroll that other machine with the JSS.

If you want to generate a QuickAdd package which has a universal multi-use enrollment invitation, you need to use the Recon application to generate the QuickAdd package. That's how I'm making the QuickAdd package which I'm using with DeployStudio.

[jcompton]

@msnowdon,

Check Rich's last suggestion first - but if you are indeed using a QA from Recon - there are several environments I know of where systems that are already in the JSS can not re-enroll. If you are finding that new systems enroll OK, but re-imaged systems are not - that may be your problem.

The workaround at that point is to edit the postinstall script in the Quick Add to use API commands to kill the computer first. I can help you with that code if you think that is the issue.

[msnowdon]

@rtrouton & @jcompton

I did create the QuickAdd package through Recon and it works when i use it without DeployStudio. I'll try again making sure I delete the Casper profile as well as the AD account before imaging.

[msnowdon]

No luck, still would not enroll in Casper. Trying to search log files but not finding anything.

[msnowdon]

Update: I created a brand new QuickAdd.pkg and copied it in the DS Respository. I Have 3 packages set to: Postponed installation, Ignore install Failures and Automate.

I re-imaged the machine again and watched the output on the screen. Everything looked good but the QuickAdd was taking a while to run. They did finish successfully and when it came back up, my software was installed and the computer was enrolled.

Weird.