Moving from CC4

[Russell83uk]

Hello,

 

This is my first post so hello to all.

 

In the summer we are moving from a CC4 network to a vanilla network.

 

I was wondering we have around 200 custom applications which we deploy the MSI files via CC4. The custom applications were created in 3rd party software.

 

So my questions is did anyone else have any problems exporting custom applications from CC4 and deploying them via SCCM like tools?

 

Russell

[ajs]

If the applications are standard MSIs that don't rely on anything CC4-specific then you shouldn't have any issues.

[sparkeh]

When you say "custom applications", can you elaborate a bit?

[synaesthesia]

Probably due to the CC4 packaging tool being "odd".

 

Anyway, the majority of CC3 and other standard MSI packages deploy perfectly fine with SCCM. Which was damn handy when we did CC3 to Vanilla

[Russell83uk]

@ sparkeh what I should have said was repackaged applications. software such as Yenka, coffee cup and so on

[sparkeh]

@ sparkeh what I should have said was repackaged applications. software such as Yenka, coffee cup and so on

Using the RM App Wiz?

Well, you may get away with it depending on how strict you were about stopping unnecessary things getting bundled up in the package (the old mapping.ver problem).

Personally I wouldn't use anything that was made with App Wiz on a vanilla network.

 

Firstly I would see which of the software uses an MSI natively and use those (eg I know than Yenka has an MSI).

Secondly, what are you going to be using to deploy the software as you could just end up using the software's native installation method (Installshield/Wise/Inno). There is a good guide here: Unattended, A Windows deployment system: Unattended/Silent Installation Switches for Windows Apps

[Russell83uk]

We don't use the RM app wizard we use Script Logic MSI Studio for the packaging. I don't trust the app wizard ha Thanks for the link.

[sparkeh]

We don't use the RM app wizard we use Script Logic MSI Studio for the packaging. I don't trust the app wizard ha Thanks for the link.

Ha wise choice.

If you are using that then I would hazard a guess that you will be fine

[Russell83uk]

Yeah I have tested a couple of applications I think most will be ok when we move from RM the desktop operating systems are staying the same windows 7 enterprise 32bit.

[ConradJones]

Yeah I have tested a couple of applications I think most will be ok when we move from RM the desktop operating systems are staying the same windows 7 enterprise 32bit.

 

Hi russell

 

have a look at app-v we use app-v for the 95% of all our apps

[mikes]

If they are all MSI's, you can copy them from the RM repoman package store, which is usually kept in RMManage\Repoman on your forest root / 001 server. Unfortunately though, the folders are named with a unique GUUID instead of the software title, so you can only tell what software is what by going into each folder individually.

[synaesthesia]

Don't know if this is still the case but do *not* navigate through the Repoman folders with Windows explorer. The addition of the desktop.ini and thumbs.db files will break packages.

[ConradJones]

SCCM does this as well because it calculates a hash based on the folder contents and the contents have changed due to the addition of the desktop.ini files. no idea why cc4 does it tho never used it.

[mikes]

Yeah, you can break packages if any files are created in Repoman since RM upd 0071 (the digest check didn't work prior to this). This is still the case. (Didn't think this mattered if you are scrapping CC4 anyway).

Strangely RM recommend browsing to Repoman and copying files out to install the RMMC on non RM workstations (will try and find the tech article).

[sparkeh]

Rather than wade through the repoman files, use the repoman viewer

http://www.edugeek.net/forums/network-classroom-management/71986-rm-cc4-repoman-guid-viewer.html

[synaesthesia]

Didn't know about SCCM, although that certainly isn't the case here at least - we often go digging into the source directories!

Then again, maybe because the desktop.ini files might already exist it might not necessarily cause an issue on subsequent visits.

[sparkeh]

Well SCCM is a bit different as you have the files in the source directory and the packages in the distribution point. If you went mucking about with the DP then I guess that would mess things up, but the source directory is fine.

[MattGibson]

We're also looking to do the same or though I'd want to recreate the packages or app v. Are there any other tools anyone can suggest? Or does SCCM pretty much cover everything in terms of management?

Would this be come you RMMC?

[synaesthesia]

There's no direct package building system in SCCM - it can handle deployment of EXE packages directly though if you so wish or standard MSI. You can continue to use something like winstallLE for original creation if need be, however there's very little software these days that isn't deployable via one standard method or another.

SCCM wouldn't entirely replace the RMMC - the latter is a mixture of AD and GPO, SCCM works alongside and with AD. A bit of a breakdown from RMMC to SCCM would be thus:

 

RMMC Functions (SCCM Equivelent)

 

User and computer account, groups, profiles etc (AD)

Software deployment of existing packages (SCCM console)

Software deployment groups (SCCM console via device or user collections)

Registry Policies (GPO/GPP)

 

There's little else that RMMC itself does anyway. To directly replace other functions from an RM network, you obviously can add AV management of System Center Endpoint Protection

Winstall LE capability is missing but you can use any standard MSI packager

System builds ala WOrkstation Build Manager/RMR via SCCM console directly

Edited May 11, 2013 by synaesthesia