Jump to content


IanLeach

Established Members
  • Content Count

    28
  • Joined

  • Last visited

Community Reputation

0 Neutral

About IanLeach

  • Rank
    Member
  1. Hi Garth and thanks for your reply. The built-in report for "Count of all instances of software registered with Add/Remove programs" returns the list of discovered apps but doesn't provide me with a corresponding exe. I'm trying to source them so I can run the PowerShell script to generate Software Metering rules. I agree, SINV reports a load of chaff that you have to wade through but given that I've around 300 apps to establish rules for, I'm happy to locate each from the endless list of executables... Any other thoughts? Ian.
  2. Hi there, I'm trying to find a way to produce an extract of all inventoried executables and then tie them back to a common application name, for example; WINWORD.EXE - Microsoft Office Word 2013 Has anyone any thoughts or queries they can share? Ian.
  3. Thanks for your answer Garth and I figured there wasn't a statement as I can usually dig and find most things, but not that. The ConfigMgr admin is looking to block access to the DB for a third party asset management tool that seems to want to access the CM12 DB directly. He's concerned about performance and stability of the tool and wanted to find an official out that he could leverage to block it. I'll advise him to speak with his TAM.
  4. Hi guys, Hopefully this will be a really simple question to answer. A customer has just asked me if I can provide the official statement from Microsoft that states what kind of CM12 database access and manipulation would make this an unsupported configuration. Whilst those of us long enough in the tooth know better than to pry too far into the database using anything other than the ConfigMgr console, I wondered if anyone had a link to the official steer from Microsoft? Thanks, Ian.
  5. Sorted this - The clients were left in provisioning mode at the end of the task sequence which prevented normal operation of the client. This only occurred for clients that failed to run a controlled shutdown at the end of the task sequence.
  6. EVERY instance is misleading. After further investigation, the clients on the CAS and PRIMARY are fully built out but not receiving AMW definitions. There are selected clients from the ones tested that are built out and don't receive AMW definition updates. The other clients exhibit the limitations highlighted in my previous post... All in all, a real mixed bag - the common theme is a lack of AMW definitions... Ian.
  7. Hi Guys, I'm experiencing some pretty funky anomalies with System Center Endpoint Protection 2012 and wondered if anyone could point me in the right direction. We are running CM12 RTM on Windows 2008 R2 SP1. My SUP, Antimalware definition updates, Policy application, client deployment (etc) have worked autonomously and reliably for quite a while now. Over the past day or so, the propagation of updates to my clients has ceased and EVERY instance of the client has the same anomaly. When I open the 'About SCEP' element of the client that displays the engines, product versions, NIS ver
  8. I always like to try and tie up forum posts when I have the resolution, so here goes... There was no Software Update Point configured on the Primary Site Server and the minute I installed and configured this role, the clients received their Antimalware definitions. Thanks for your help guys, Ian.
  9. Cheers Guys, the logic behind what you've said is sound. It's always best to throw something like this out there and see what comes back. Ian.
  10. Hi Guys, This is a really simple question I think and wondered if anyone had a definitive answer... If a user sets their business hours as 00:00 to 00:00 for every day of the week, does this mean that the machine believes it's in use 24/7 and no software updates etc are deployed to the client? Or does it mean that effectively the user has no business hours? I just don't want anyone to have the ability to block any critical management activities. Thanks, Ian.
  11. I'm triggering it manually using the Update button after ensuring any policy changes are applied to the client. The machines that are policy-triggered are failing similarly...
  12. Right. I've got something further to add to this. After completing some reading about SCEP, I think my initial question regarding MMPC has been answered. It would appear that the initial client definitions are updated from whichever of the five sources it has success with, whether they are specified in the AMW policy or not. My problem is now with the error code I stated in my initial message. The WindowsUpdate.log shows numerous failures (all with error code 0x8024402c) and the WUAHandler.log doesn't vaguely reflect that shown in the troubleshooting example. This is the WUAHandler.log
  13. Cheers Niall. I'll run through the troubleshooting and post an update here ASAP.
  14. OK, a little bit of further testing has revealed the following: Clients with a valid proxy server update their definitions when the proxy configuration is enabled. When the proxy is disabled, the client fails to update. To me, this points at MMPC being credible as the update source but doesn't explain why the SUP isn't servicing requests from the SCEP clients... Ian.
×
×
  • Create New...