locked
Uninstalling of SCCM Client of from a machine Error RRS feed

  • Question

  • Hello, I am trying to uninstall the client from the machine and I am watching the entire process with sms trace. It generates an error though "WARNING: Cache sub directory could not be deleted. Error 0x80070002" for all the packages that once were pushed, but they are no longer in the Cache directory since they were manually deleted. It attempts to delete it 31 times after which it moves on to the next package. The whole process is extremely time consuming. How can I fix this? Is there a registry entry or something for this? Thanks!
    Friday, March 1, 2013 1:56 PM

Answers

  • Hi,

    I have never seen a Configuration setting for that, the sccm client knows all files that should be in the cache directory and will try to delete them, the Cache directory should not be deleted manually, nor the content in it.

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    Friday, March 1, 2013 2:05 PM

All replies

  • Hi,

    I have never seen a Configuration setting for that, the sccm client knows all files that should be in the cache directory and will try to delete them, the Cache directory should not be deleted manually, nor the content in it.

    Regards,
    Jörgen


    -- My System Center blog ccmexec.com -- Twitter @ccmexec

    Friday, March 1, 2013 2:05 PM
  • Thank you for the response, how does the SCCM client knows about the files that should be in that cache? There got to be some reference file or a database entry somewhere??
    Thursday, March 7, 2013 3:19 PM
  • It's all in WMI. It doesn't keep track of all files, just the top-level folders in the cache.

    Restarting the client agent may cause it to review the cache and reconcile differences and is worth trying before you uninstall.


    Jason | http://blog.configmgrftw.com

    Thursday, March 7, 2013 4:35 PM
  • I have been having the same problem at a client's site upgrading from 2007 R3 to 2012. Not sure whats causing it yet but I have found rebooting while its trying to delete the cache subfolders will usually allow the machine to resume the client upgrade and complete successfully. This problem has occurred on 3 of the 5 workstations I have upgraded.

    I am thinking perhaps trying to clear the cache or repair WMI before starting the upgrade might fix it. If I find a work around I will post it

    • Proposed as answer by Fazal(MCTS) Monday, March 25, 2013 1:29 PM
    Monday, March 25, 2013 4:45 AM
  • I am Suggesting first repair the WMI; go to C:\Windows\System32\wbem rename old as Repository (E.G; Repository_old) and restart the WMI service

    Second Clear cache and Uninstall SCCM client CMD go to file path and E.G; C:\windows\system32\ccmsetup>ccmsetup.exe /uninstall

    Third if its not work out install client again or repair and see

    Monday, March 25, 2013 1:29 PM
  • I am Suggesting first repair the WMI; go to C:\Windows\System32\wbem rename old as Repository (E.G; Repository_old) and restart the WMI service

    Second Clear cache and Uninstall SCCM client CMD go to file path and E.G; C:\windows\system32\ccmsetup>ccmsetup.exe /uninstall

    Third if its not work out install client again or repair and see

    Monday, March 25, 2013 1:29 PM
  • I am Suggesting first repair the WMI; go to C:\Windows\System32\wbem rename old as Repository (E.G; Repository_old) and restart the WMI service

    Second Clear cache and Uninstall SCCM client CMD go to file path and E.G; C:\windows\system32\ccmsetup>ccmsetup.exe /uninstall

    Third if its not work out install client again or repair and see


    That does not in any way repair WMI and should not generally be used except as a last resort. It is destructive and completely deletes the repository causing Windows to rebuild it and possibly losing data in the process. Depending upon your OS, there are actual ways to repair the repository.

    Jason | http://blog.configmgrftw.com

    Monday, March 25, 2013 1:41 PM
  • I think I figured out what’s going on for us. I compared the failed cache deletions in the log to what’s actually in the cache on my VM. Turns out the stuff in the log simply wasn’t in the cache, hence the error. This is because I have uninstalled and reinstalled the client on my VM manually for whatever reason in the past. When you uninstall it, apparently the WMI repository it creates, stays, yet the cache folder is emptied and recreated blank. In that repository, among other things, is a history of what *should* be in the cache. The uninstaller looks to wmi and then looks to the cache and it doesn’t match. For each one that was removed it retries and eats up time.

    In your case it is because for some reason you are manually deleting packages from the cache. Which you should probably never do.

    Do we know of a WMI script that will look for these orphaned WMI entries for cache items and delete them?

    Thanks

    Friday, July 12, 2013 8:41 PM