# software updates available

jarednichols
Honored Contributor

Anyone seeing the # of software updates available not being reflected properly?

We have an internal SUS that we point users to via MCX (via Casper) with the complete catalog URL string and machines that obviously require patches (e.g. On 10.6.2) show up as no software updates available.

Thanks
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

7 REPLIES 7

tlarkin
Honored Contributor

Are your servers 10.6.4? From my understanding a SUS will not download and display any update it cannot install itself? Someone may need to correct me on that one.

jarednichols
Honored Contributor

Yes. Server's fully patched.

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

jarednichols
Honored Contributor

Some newly discovered information:

If I initiate Software Update from the client, it shows that the appropriate updates are available. So, it's pointed to the right place.

If I run a "jamf recon" I get an error when it's collecting receipts:
"Cannot connect to swscan.apple.com. There may be a proxy in place."

Well, yeah, we have a proxy in place, but more importantly, why is the machine trying to connect to swscan.apple.com if it's correctly pointed at my SUS?!

Anyone?

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

ernstcs
Contributor III

What I was wondering if some of the OS updates were actually changing back the local computers software update pointer, which means you’d have to set it again. I know I have my clients set to my internal, but I find over time they are somehow going back to Apple!

Then I just thought...hey, I could have an Extended Attribute that checks and reports back which SUS is configured on the client during a recon. I could then scope a smart group to prompt to correct those systems that are not set to what I want with a policy!

I <3 Extended Attributes

Craig E

jarednichols
Honored Contributor

Yeah I thought about that too (reverting to Cupertino) but I've got SUS defined with MCX. I've verified that the machine next to me exhibiting this issue is indeed pointed at our SUS and not Cupertino. If Software Update is invoked from the client, it sees the available updates from our SUS. It's just in when it's Recon'd that something is not quite right (which I assume the "Cannot connect to swscan.apple.com. There may be a proxy in place" message is a symptom of.)

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

jarednichols
Honored Contributor

Some added information…

I figured, heck, why not give it a proxy. So, I did an "export http_proxy" command and defined our proxy. I then ran a jamf recon and wouldn't you know, no error about not finding swupdate.apple.com.

Now to figure out if it's actually pointed at Cupertino or our SUS. I disabled iTunes 9.2 on our SUS and ran recon again. Didn't say iTunes 9.2 was active. Lit up iTunes 9.2 again and recon'd again. 9.2 available.

So, it definitely looks at our SUS, but why the heck does it care that our proxy is defined?!?!

j
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

sirkyle
New Contributor III

Jared,

Were you ever able to resolve this issue? Our machines are experiencing the same behavior when checking for available updates during recon. Other than that, all machines are pointed to our internal SUS.

I look forward to your response!