Jump to content


squmph

Established Members
  • Posts

    8
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by squmph

  1. So I stopped the collection evaluator component... that was obvious Didn't help one bit; still at 100%. Worked my way down all the components stopping them. Now the only one running is the sms executive, and we're still on 100%. I've had nothing new in either of the two standard log locations for several minutes - even ccmexec.log has nothing useful in it. Have now started digging into SQL and I think that the plan which is doing this is running the following query: select ScopeName, SearchBase, Group_ObjectGUID, IsNestedGroup from vAllImmediateSearchBase_Group Help!
  2. Hi all, We have a single primary site on 2012 R2 SP1 comprising of a central site server and dedicated SQL server, both 2008 R2. We have lots of remote sites which are all set up as secondaries. A few days ago, processor usage on our SQL box went through the roof. It sits at 99% constantly. The only way to stop it seems to be to stop SQL, or stop smsexec on the site server. As soon as you start them again, there it goes. I've been trying to dig into this, and have found that our collections seem to be performing incremental updates at an insane rate. Colleval viewer tells me we have 94 collections, and 70 of them have performed an incremental update in the last 3 minutes. They only took a few seconds each and aren't queuing, but I think this seems pretty likely to be my cause. Unfortunately... I have no idea what to do about this, short of disabling delta updates for all collections to see what happens. Any ideas please? Our estate is otherwise unaffected, apart from a few entries in various logs about rather understandable SQL timeouts, and general slowness. Thanks Rob
  3. It sounds like something is overwriting an essential component of the client config some time after OSD completes, or something is changing your network config and preventing access to your MP. 3 hours is a bit long, but my first thought would be GPO - faesibly something could be getting screwed up by a rogue script or preference shortly after OSD completes, which explains why the client behaves abnormally. Some time after that the client has failed to contact the MP for so long that it starts losing capabilities. Alternatively, one of these 8 hotfixes or anything else which runs in your TS after the CM client could also be screwing this up, but I get the feeling you would know... As for your 8 apps, my guess would be that the 6 which don't register as already installed either failed install during the TS, but didn't trigger a TS exit, or your compliance detection method isn't robust. I might look at what the AppEnforce log tells you when they try to install, and you could dig through the TS log to see if the installation succeeded? If you actually have the patches injected into the WIM, then I think your issue will be with compliance detection. The fix you've referenced seems to be for SCCM infrastructures utilising a PKI for client comms - if this is something you are doing, then I would look into issues with the client auto-enrolling for its cert, and using this cert for client comms. If not, this is a red herring. Also, the reg key specified is delaying user policy which is a little odd, as this issue would appear to be related to machine policy. Rob
  4. Hi all, We have our entire estate encrypyted with Bitlocker (TPM). I am trying to work out the best way to deploy a BIOS update using HP's HPQFlash utility. This is not a problem without Bitlocker - it's just a matter of deploying HPQflash with the right bits and parameters. However, on an encrypted machine, Bitlocker has to be suspended during the update because various values in BIOS are changed as part of the process, which can (and does) cause the TPM to decide it doesn't trust the system. So I need the process to work like this: 1) Suspend Bitlocker (manage-bde -protectors -disable c:) 2) Run the update (HPQFlash -s etc etc etc) 3) Complete a reboot to apply the update, which SCCM recognises by the return code of the above. This must not happen while the machine is in use - it would be best if it just waits for the user or another process to perform the reboot (as it does currently) and we will cope with bitlocker being off for a while. 4) Resume Bitlocker (manage-bde -protectors -enable c:) Can anyone suggest the best way of doing this please? Step 3 is the difficult bit I feel. Thanks Rob
  5. Solved myself. Just incase anyone else hits this: Looked at the MP_Framework log on the sec site (other MP logs seemed OK), and every time PXE failed it reported this: CMPDBConnection::ExecuteSQL(): ICommandText::Execute() failed with 0x80040E09 MpFramework 17/10/2013 10:04:59 2984 (0x0BA8) ======================================= MpFramework 17/10/2013 10:04:59 2984 (0x0BA8) MPDB ERROR - CONNECTION PARAMETERS SQL Server Name : (MySiteServer)\CONFIGMGRSEC SQL Database Name : CM_(Site) Integrated Auth : True MPDB ERROR - EXTENDED INFORMATION MPDB Method : ExecuteSP() MPDB Method HRESULT : 0x80040E09 Error Description : The EXECUTE permission was denied on the object 'sp_GetPublicKeyForSMSID', database 'CM_(primarysite)', schema 'dbo'. OLEDB IID : {0C733A63-2A1C-11CE-ADE5-00AA0044773D} ProgID : Microsoft SQL Server Native Client 11.0 MPDB ERROR - INFORMATION FROM DRIVER SQL Server Name : (primarySQL)\SCCM Stored Procedure : sp_GetPublicKeyForSMSID Native Error no. : 229 Error State : 5 Class (Severity) : 14 Line number in SP : 1 MpFramework 17/10/2013 10:04:59 2984 (0x0BA8) ======================================= MpFramework 17/10/2013 10:04:59 2984 (0x0BA8) CMpDatabase::GetClientPublicKeyEx(ClientID='23d0e153-9c60-417a-8184-b1fcb1a79caf') failed (0x87d00242). MpFramework 17/10/2013 10:04:59 2984 (0x0BA8) After much faffing about, I found the referenced SP on the primary site SQL server. The SQL login for the computer account looked present and correct, and the execute permissions made sense. As I had rebuild the server, there was a possibility that the SQL login was referencing an old SID... So I: 1) Deleted the SQL login for the secondary site server (on the primary site SQL server) 2) Deleted the login from the primary DB for good measure 3) recreated the login, must be done by script: "Create login [domain\secsiteserver$] from windows;" 4) re-mapped the login to the primary site DB, granting role "smsdbrole_MP" 5) rebooted the secondary site server. This worked immediately... Hope that helps someone Rob
  6. Hi all, We have an installation of CM2012 SP1 in our forest root, with secondary sites in a couple of child domains at different sites. This is all working fine (including PXE). We are trying to get a new secondary site working, again at a different site, but on the same domain as an existing secondary site (so we know that it works). Installation goes fine & installation of PXE goes fine too, but when the PXE provider starts and/or a client requests PXE, the smspxe log displays the following: reply has no message header marker SMSPXE 17/10/2013 09:29:32 5272 (0x1498) PXE::MP_LookupDevice failed; 0x80004005 SMSPXE 17/10/2013 09:29:32 5272 (0x1498) reply has no message header marker SMSPXE 17/10/2013 09:29:32 5272 (0x1498) Failed to send status message (80004005) SMSPXE 17/10/2013 09:29:32 5272 (0x1498) Failed to send the status message SMSPXE 17/10/2013 09:29:32 5272 (0x1498) PXE::MP_ReportStatus failed; 0x80004005 SMSPXE 17/10/2013 09:29:32 5272 (0x1498) PXE Provider failed to process message. Unspecified error (Error: 80004005; Source: Windows) SMSPXE 17/10/2013 09:29:32 5272 (0x1498) 00:15:5D:91:42:27, F44C341E-17F1-43D9-B774-F9122D697F00: Not serviced. SMSPXE 17/10/2013 09:29:32 5272 (0x1498) It repeats the above every time a client sends a request. The client eventually times out with PXE-E53. So what have we done to try and fix this: 1) confirmed that the MP is OK (MPControl says fine, and checked MPcert/MPlist) 2) removed the PXE service point and re-added, including reboots, deletion of remoteinstall folder & temp folder 3) rebuilt the server twice - once from template and once from CD At this point I am completely stuck for ideas. Google finds a few errors like this, but most are down to certificate issues and have lines mentioning this - we are using basic HTTP on the MP and DP. Help! Rob
  7. Hi, We have an installation of SCCM 2012 SP1 with a single primary and several remote secondary sites (hub and spoke). A recent installation of an additional secondary site is not working as expected. Specifically, issues were encountered with the PXE component (working fine at other sites). Usual troubleshooting was performed followed by a pretty routine removal of the PXE component (untick the box), with the intention of reinstallation later. The uninstallation was not indicated in the distmgr log on the secondary site, but the smspxe log indicated a shutdown and never started again. WDS was uninstalled manually and RemoteInstall was deleted. There was nothing relevant to remove in %windir%\temp. The server was then rebooted. For the past 2 days I have been trying fruitlessly to get the PXE components to install again. The DP config accepts the various tickboxes (and I have tried workarounds for the bug in previous version relating to this), but the installation never happens after several hours of waiting. Performing a reboot before enabling the component makes no difference. Distmgr on the secondary site never mentions the installation - all we ever see are the various expected "sleep" entries. WDS never installs. No errors are logged for the site or components in the monitoring console. As a last resort I uninstalled the Secondary site and reinstalled it several hours later. The same issue recurs - After enabling PXE, nothing happens. Can anyone help please? Thanks Rob
  8. Hi all, We have a production SCCM 2012 RTM (not SP1) setup with a central primary site and three child sites. A few weeks ago, software stopped deploying to some machines at at least two of the child sites. On investigation, the affected clients didn't seem to have picked up their client config (although they used to have it?!) - the only client actions available were the two policy retrieval actions. This was resolved by running a standard machine policy retrieval, but did not make the software deploy or appear in software center. After some looking around I came across an article by Torsten, which described the scenario completely: http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http%3A%2F%2Fwww.mssccmfaq.de%2F2013%2F03%2F15%2Ffehlende-applications-im-software-center Running the DCM trigger VB on a broken machine (which had had its policy manually retrieved) caused the deployed apps to appear in the software center. However, they showed up with a status of "past deadline - will be installed". At this point it was possible to install the apps from software center which completed successfully. However, that's obviously not much use as a fix or workaround (might aswell just install manually). If a machine was left in this state, after about 24 hours the applications had disappeared from software center again without installing. You can run the VB again to make them re-appear/rinse and repeat. This one has me completely stumped. I've been through most of the relevant logs but have come up with no obvious errors. Site/component status (all sites) all OK etc etc... The only other thing I can think to note is that even if you perform the software installation manually from software center, the app will never show up as successfully installed from SSRS. Any ideas please? Thanks Rob
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.