RM CC4 Questions / Adobe Reader Package

[Steve21]

Good Morning All,

 

We have recently been asked to look at a local school who’s still using RM CC4 and I just had a few questions for anyone in the know

 

Do you “have” to use the RM console for everything? Or can I still deploy software via GPO? Set updates via WSUS console etc?

 

Just seems odd that they don’t have things like any updates deployed in two years, and wasn’t sure if RM restrict one’s that they’ve checked etc or if Noones just deployed them

 

Still waiting on getting access to the RM support portal as everything help article seems locked!

 

Also, does anyone have a Adobe reader package they wouldn’t mind sharing? Seems there isn’t an App Wizard computer setup and it doesn’t seem to like importing non-RM packages, and they want to use some old software that only works with Adobe Reader

 

Many thanks,

Steve

[clareq]

From memory (disclaimer: it's been many years since I worked on a CC4 network), RM packages are just .msi - you should be able to use the Adobe Reader packaging program, available from https://www.adobe.com/devnet-docs/acrobatetk/index.html to build a msi and import it.

[Steve21]

From memory (disclaimer: it's been many years since I worked on a CC4 network), RM packages are just .msi - you should be able to use the Adobe Reader packaging program, available from https://www.adobe.com/devnet-docs/acrobatetk/index.html to build a msi and import it.

 

Thanks, Yeah I did think that should work, but CC4 only seems to let you import the xml meta datas which I think it was the App Wizard that made them. Guess I could manually knock one up if worse comes to worse copying it from another package

 

Many thanks,

Steve

[clareq]

I could definitely import msi's into the console without using AppWiz. In fact, I just found a post here, that I made back in 2011, with instructions on how to do so:

 

http://www.edugeek.net/forums/o-s-deployment/75964-deploying-msi-rm-cc4-network.html

[foofighterjim]

From memory, WSUS is handled from within the RMMC, there will probably be a GPO in place directing the clients to the local server for the updates. If updates aren't being deployed I would look into the cause first rather than just circumventing it, RM definitely used to check the updates before allowing deployment, no idea if this is still the case though.

[atcoates]

Application Wizard is not needed, just grab the MSI and import it into CC4 with a package ini file. For the last adobe package we made we created a transform file so it just updated itself so have never needed to update it manually.

 

If you can access rm.com they have a full pdf on how to create packages here.

 

CC4 packaging guide

Published Date : 20 Feb 2013 Last Updated : 19 Oct 2021 Content Ref: DWN3152898

 

Also this for wsus which is all automated on CC4 so if clients aren't getting updates or wsus isn't synching to Microsoft they have a tool...

 

Index article for WSUS on Community Connect 4

Published Date : 25 Feb 2016 Last Updated : 27 Jan 2022 Content Ref: TEC5026777

 

what the tool does...

 

The Community Connect® 4 (CC4) WSUS health check tool is a collection of PowerShell scripts that perform a number of common troubleshooting steps for WSUS implementations on CC4 networks.

 

The tool is made up of a number of scripts that will perform a number of checks as follows:

 

Checks the Windows services related to WSUS.

Checks the update classification options selected within WSUS.

Checks the update product category options selected within WSUS.

Checks the language settings selected within WSUS.

Checks the automatic approval rules within WSUS.

Checks the proxy settings specified for WSUS.

Checks for and declines approved updates that are now superseded.

Checks for any Microsoft hotfixes that are required to improve the stability of WSUS.

Checks the WSUS AppPool settings specified within Internet Information Services (IIS).

Checks for CC4 software updates (CC4UPDs) necessary for WSUS.

Checks for duplicate CC4 WSUS scheduled tasks being created.

Checks the scheduled times that WSUS will synchronise with the Microsoft and RM servers.

Checks the scheduled times that client devices will synchronise with the WSUS server.

Installs Microsoft Report Viewer 2012 if required.

Runs a comprehensive WSUS clean up script.

Note: This tool is only supported on a CC4.5 (Windows Server 2012 R2) or CoP (Windows Server 2016 or 2019) CC4 First server.

Currently, it's not supported on multi-site networks.

Edited November 30, 2022 by atcoates

[David44]

To package an MSI in RM CC4, create a new folder put the MSI and any other files that are needed as part of the installation in to it, transform files or similar.

 

Optionally, create a readme.txt file in the same directory with any details you think relevant to the package. This will appear in the readme tab when you later check the package properties.

Optionally, create a folder called shortcuts and copy any shortcuts that point to the software you are installing in to this folder.

 

In RMMC, go to File>Import> Package and select 'Community Connect 3 Package' (this is correct, choose CC3 and not CC4, even though you are using CC4. The RMMC hasn't had any major update in years).

Click on 'Show package properties after importing' and then click on Browse and browse to the MSI in the directory that you created earlier.

When the package properties appear, change anything relevant such as the name of the package, command line options and which OSes it is compatible with etc.

Click on Ok, you should now have a package.

 

You might actually have two packages because it creates the package when you import it and then creates a new package when you make any changes to the properties. You can delete the first one it created by going to Software> Packages & Products> All Packages in RMMC and right-clicking on it and selecting 'Remove from Network'.

 

People have mentioned needing an .ini file. This is not the case when the package is created from an .msi file. If you were installing from a .exe or .cmd etc. then you'd need to include an .ini file too.

[atcoates]

T

You might actually have two packages because it creates the package when you import it and then creates a new package when you make any changes to the properties. You can delete the first one it created by going to Software> Packages & Products> All

 

People have mentioned needing an .ini file. This is not the case when the package is created from an .msi file. If you were installing from a .exe or .cmd etc. then you'd need to include an .ini file too.

 

If you create the ini file correctly all this information will be auto imported and you won't end up with two packages.

[Steve21]

Thanks all! Much appreciated, will have a flick through it this afternoon and see where I get.

 

Looks like lots of resources on their support so will need to get that login sorted

 

Many thanks,

Steve