Hi’all,
Would anyone know how easy or difficult to import packages from a prior environment such as INTUNE or SCCM to Bigfix, would it at least be compatible / feasible ?
Furthermore, I`d love to get an overview of the workload & time this could take per package ?
Thank a lot.
Everything that follows should be understood that I have never made any packages in SCCM or INTUNE. I am only sharing this information with my experience creating deployments within BigFix.
I’m not aware of any kind of wizard that would made a straight import from either tool possible. The deployments would have to be recreated either using the Software Distribution Wizard or by creating fixlets by hand if you’re capable.
How many packages are you looking to migrate?
As @jmaple stated, there is no built-in way to migrate the content.
To migrate them to Tasks should be relatively easy – the hard part of making BigFix content is often getting the thing to work scripted in the first place – you’ve already got that done with SCCM.
The hard part is your teams have probably been using SCCM without any applicability criteria (fire and forget deployments). You can do this in BigFix with tasks (more fire and forget type of content) but you’re better off making fixlets with actual relevance statements.
I’ve done a bunch of SCCM -> BigFix migrations and once whomever is doing it gets into the, “Groove” of doing it you’re looking at 5-15 minutes per SCCM package with some taking 2+ hours. Most of the time if it takes more than 15 minutes it’s because it was done incorrectly in SCCM to begin with and whomever is migrating the content gets to fix it.
I have not done SCCM to BigFix before, but I did work on a project to convert TCM (Tivoli Configuration Manager) packages to BigFix.In some ways this could be similar.
I guess one of the issues is that everyone does it differently, so it is really hard to give a solution for this. 
If your SCCM packages are mostly MSI, you can script quite a bit of the conversion, including the relevance.
From what I can recall, you can export the packages from SCCM so that you can get the command line that is used. This is what will go in your “wait/waithidden”. You will just have to modify where the MSI file is located, which is most likely __Download/.
With the MSI, you can get the product code, which can then be used to create your relevance. I used something similar to this http://www.itninja.com/blog/view/reading-an-msi-setup-with-vbscript to do that part.
You can also use bfarchive.exe and sha1.exe to build the compressed file and the prefetch command.
I did all of this with a PERL script just because that is what I was used to using. The other thing you can do is also build the removal package at the same time as you have all the information needed. For each package, I would prefix it with "Deploy: " and "Remove: ".
Now if most of your packages are EXE installs, then you can do pretty much all the same things except automatically build the relevance based on the product code. You could come up with something else like a special file or registry entry that you build into the deploy package.
Just some thoughts
Martin
Hello all ,
@TheTick, @strawgate & jmaple
Thanks to all of you , this is much clearer and I appreciate your responsiveness.
Keep up 