none
After installing patches 4459922 and 4462923 from 10/9/18 I can no longer access administrative shares like C$ on a remote machine

    Question

  • As part of our usual patch Tuesday process we download the patches from Windows update and ran them on a group of test computers. After installing the patches from 10/9/2018 - 4459922, 4462923, 890830 - Sept, we can no longer access the administrative share C$ on the remote machine. According to what I could find I needed to install 3177467 first (which wasn't available in the downloads until today 10/10/2018). I installed 3177467, which is some sort of stack update, and rebooted. Still cannot see the C$ on machines were the patch was tested. I tried to reinstall 4459922 and 4462923 after installing 3177467 but both patches indicated they were already installed. I uninstalled 4462923 but could not find 4459922 to uninstall. Still can't access the C$ share remotely. No problem accessing it locally.

    Thoughts


    eburch@lasertel.com


    • Edited by EWB_2 Wednesday, October 10, 2018 11:01 PM
    Wednesday, October 10, 2018 6:19 PM

Answers

  • Finally figured out what happened - typo in a group policy object!

    We have two main GPOs which we use to manage workstations - one of which uses WSUS in auto download/ auto restart mode and the other one does auto download but manual install and reboot. Servers and workstations that have to be scheduled to reboot go in the second GPO. In the first GPO, in the list of subnets that allow file and print sharing, there was a typo a "/" instead of a "," in the list. That effectively prevents any file and print sharing to those affected machines. Of course all the test machines that we use were in the first GPO. It did not affect the servers or the non-rebooting workstations because they are in the 2nd GPO.

    The confusing part was the apparent relations to patches. The GPO change happened the Sunday before patch Tuesday and the error was not detected until after the patches as part of our usual post patch testing which made it appear to be related to the patches. 


    eburch@lasertel.com


    • Marked as answer by EWB_2 Tuesday, October 30, 2018 12:09 AM
    • Edited by EWB_2 Tuesday, October 30, 2018 12:11 AM
    Tuesday, October 30, 2018 12:09 AM

All replies

  • One might set as C$  as default OS,but Microsoft/Windows is/always been C: 

    To reconfigure C:  to other,simply will not work..Microsoft is specific on this....Also,to reinstall,use Windows Update Catalog,use the link..

    http://catalog.update.microsoft.com/v7/site/Search.aspx?q=Windows%207

    Wednesday, October 10, 2018 9:51 PM
  • Not sure what you mean. We use the \\computer\C$ share all the time to access systems around the network. On the machines where the patches were installed from Tuesday we can no longer access those systems via the C$ share. 4459922 was a .net patch and 4462923 was the monthly rollup for Windows 7 SP1.

    eburch@lasertel.com

    Wednesday, October 10, 2018 11:05 PM
  • Hi,
    We use command to see if we have installed the four KB number update:4459922, 4462923, 890830 and 3177467.
    1. Open "PowerShell", run as Administrator.
    2. Type Get-hotfix, click Enter.
    3. Then we get the KB number update lists like this:

    We view the installation time and KB number, if we do install these four KB number updates. We try to uninstall them, then we view if the issue still exists.

    If we uninstall these four KB number updates, the issue will disappear. Then we reinstall these KB number updates, then we view if the issue persists.
    Does this happen when multiple computers update these patches?

    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, October 11, 2018 6:06 AM
  • So I uninstalled everything that indicated it was installed on either 10/9/18 or 10/10/18:

    4457144, 4457008, 4457426, 4457145, 4457016, 4343900 (I  tried to uninstall 3177467 but it was not available for uninstall)

    Rebooted and still no success. It was odd that 4 .Net patches now show up as installed today which I am guessing is some sort of patch reversion that is going on.

    After the reboot I had 4 patches due - 4343899, 4457426, 4457144, and 4457145 all due. These are all patches from the September Patch Tuesday. Installed them again and rebooted - still no remote access to the C$ share on the test machine. I can access the C$ share locally using \\Computername\C$.


    EWB


    • Edited by EWB_2 Thursday, October 11, 2018 10:31 PM
    Thursday, October 11, 2018 9:52 PM
  • Hi,
    We try the following way to uninstall the KB 3177467:
    1. Open "PowerShell", run as Administrator.
    2. Type dism /online /get-packages >C:\KB.txt(KB is the file name.)
    3. Click Enter.
    4. Find the KB.txt in C. When we open the file, we can see a lot of the contents as below:

    Package Identity : Package_for_KB4457146~31bf3856ad364e35~amd64~~10.0.1.0
    State : Installed
    Release Type : Security Update
    Install Time : 9/12/2018 2:46 AM

    5. We try to uninstall the KB 3177467 in PowerShell, type dism /online /remove-package /packagename:Package_for_KB4457146~31bf3856ad364e35~amd64~~10.0.1.0
    6. If we uninstall the KB 3177467, then we view if the issue still exists.

    Note:we need to change the corresponding Package Identity when we remove package.

    Best Regards,
    Daisy Zhou

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.



    Friday, October 12, 2018 9:32 AM
  • Ran as suggested but received error:

    PS C:\Windows\system32> dism /online /remove-Package /packagename:Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5

    Deployment Image Servicing and Management tool
    Version: 6.1.7600.16385

    Image Version: 6.1.7601.18489

    Processing 1 of 1 - An error occurred - Package_for_KB3177467 Error: 0x800f0825

    Error: 0x800f0825

    DISM failed. No operation was performed.
    For more information, review the log file.

    The DISM log file can be found at C:\windows\Logs\DISM\dism.log

    Relevant part of DISM.log:

    2018-10-12 09:37:57, Info                  DISM   DISM.EXE: Succesfully registered commands for the provider: Edition Manager.
    2018-10-12 09:37:57, Info                  DISM   DISM Provider Store: PID=6444 Getting Provider DISM Package Manager - CDISMProviderStore::GetProvider
    2018-10-12 09:37:57, Info                  DISM   DISM Provider Store: PID=6444 Provider has previously been initialized.  Returning the existing instance. - CDISMProviderStore::Internal_GetProvider
    2018-10-12 09:37:57, Info                  DISM   DISM Package Manager: PID=6444 Processing the top level command token(remove-package). - CPackageManagerCLIHandler::Private_ValidateCmdLine
    2018-10-12 09:37:57, Info                  DISM   DISM Package Manager: PID=6444 Attempting to route to appropriate command handler. - CPackageManagerCLIHandler::ExecuteCmdLine
    2018-10-12 09:37:57, Info                  DISM   DISM Package Manager: PID=6444 Routing the command... - CPackageManagerCLIHandler::ExecuteCmdLine
    2018-10-12 09:37:57, Info                  DISM   DISM Package Manager: PID=6444 Encountered the option "packagename" with value "Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5" - CPackageManagerCLIHandler::Private_GetPackagesFromCommandLine
    2018-10-12 09:37:57, Info                  DISM   DISM Package Manager: PID=6444 Package Package_for_KB3177467~31bf3856ad364e35~amd64~~6.1.2.5 with CBS state 7(CbsInstallStateInstalled) being mapped to dism state 5(DISM_INSTALL_STATE_INSTALLED) - CDISMPackage::LogInstallStateMapping
    2018-10-12 09:37:57, Info                  DISM   DISM Package Manager: PID=6444 Initiating Changes on Package with values: 5, 0 - CDISMPackage::Internal_ChangePackageState
    2018-10-12 09:37:57, Error                 DISM   DISM Package Manager: PID=6444 Failed initiating changes - CDISMPackage::Internal_ChangePackageState(hr:0x800f0825)
    2018-10-12 09:37:57, Error                 DISM   DISM Package Manager: PID=6444 Failed to Remove the Package. - CDISMPackage::Remove(hr:0x800f0825)
    2018-10-12 09:37:57, Error                 DISM   DISM Package Manager: PID=6444 Failed while processing command remove-package. - CPackageManagerCLIHandler::ExecuteCmdLine(hr:0x800f0825)
    2018-10-12 09:37:57, Info                  DISM   DISM Package Manager: PID=6444 Further logs for online package and feature related operations can be found at %WINDIR%\logs\CBS\cbs.log - CPackageManagerCLIHandler::ExecuteCmdLine
    2018-10-12 09:37:57, Error                 DISM   DISM.EXE: DISM Package Manager processed the command line but failed. HRESULT=800F0825
    2018-10-12 09:37:57, Info                  DISM   DISM Image Session: PID=6444 Disconnecting the provider store - CDISMImageSession::Final_OnDisconnect
    2018-10-12 09:37:57, Info                  DISM   DISM Provider Store: PID=6444 Finalizing the servicing provider(DISM Package Manager) - CDISMProviderStore::Internal_DisconnectProvider
    2018-10-12 09:37:57, Info                  DISM   DISM Package Manager: PID=6444 Finalizing CBS core. - CDISMPackageManager::Finalize
    2018-10-12 09:37:57, Info                  DISM   DISM Provider Store: PID=6444 Disconnecting Provider: DISM Package Manager - CDISMProviderStore::Internal_DisconnectProvider

    Get-hotfix confirmed patch not uninstalled

    Interesting side note. Affected Windows 7 computers cannot access C$ share on XP machines but can access C$ share on unaffected Windows 7 machines.

    Thoughts


    eburch@lasertel.com


    • Edited by EWB_2 Friday, October 12, 2018 4:55 PM
    Friday, October 12, 2018 4:46 PM
  • Hi,
    Try the following way to uninstall the KB 3177467.
    1. Open command prompt, run as Administrator.
    2. Type wusa.exe /uninstall /kb:3177467.
    3. Click Enter.

    If it does not work, we check if the default share is open.
    1. Open command prompt, run as Administrator.
    2. Type net share.
    3. Click Enter.

    If the default share is open, we check the share setting according to 1)-8) in the article.

    Tip: This answer contains the content of a third-party website. Microsoft makes no representations about the content of these websites. We provide this content only for your convenience.

    Best Regards,
    Daisy Zhou


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.


    Monday, October 15, 2018 2:10 PM
  • The default share C$ exists and is accessible locally i.e. \\computername\C$ works locally but not from another computer. I can open C$ on other non-patched computers but not on the ones that were patched. When I tried to uninstall the patch I received a pop up "Security Update for Microsoft Windows (KB3177467) is required by your computer and cannot be uninstalled."


    eburch@lasertel.com


    • Edited by EWB_2 Tuesday, October 16, 2018 6:40 PM
    Tuesday, October 16, 2018 6:12 PM
  • Hi,
    We suggest that we find a computer that does not have KB installed, and we can access C$, then install this KB3177467 on this computer. If before we install this KB3177467, we can access C$ normally. However, after installing this KB3177467, we can't access C$. It means that we can't access C$ because we installed this KB3177467, and we can't uninstall this KB3177467 now. Then we suggest we consider reinstalling the operating system.

    If the problem is caused by installing this KB, we can consider the way as above, if not, it may caused by other reasons.

    Best regards,
    Daisy Zhou


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Wednesday, October 17, 2018 6:20 AM
  • Hi,
    If this question has any update? Also, for the question, is there any other assistance we could provide?
    Best Regards,
    Daisy Zhou


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Friday, October 19, 2018 7:37 AM
  • Still trying to find the combination that recovers these machines. Re-installing the OS is not a fix. Clearly had this happened in larger scale it would have been catastrophic especially on OSs that don't allow you to chose which updates will install like Windows 10 and Server 2016. I need to understand what mechanism is different between accessing administrative shares locally versus over the network. If I can access administrative shares locally and I can successfully RDP into affected machines then we should be able to determine what is unique about accessing administrative shares over the network.

    eburch@lasertel.com

    Friday, October 19, 2018 4:05 PM
  • Finally figured out what happened - typo in a group policy object!

    We have two main GPOs which we use to manage workstations - one of which uses WSUS in auto download/ auto restart mode and the other one does auto download but manual install and reboot. Servers and workstations that have to be scheduled to reboot go in the second GPO. In the first GPO, in the list of subnets that allow file and print sharing, there was a typo a "/" instead of a "," in the list. That effectively prevents any file and print sharing to those affected machines. Of course all the test machines that we use were in the first GPO. It did not affect the servers or the non-rebooting workstations because they are in the 2nd GPO.

    The confusing part was the apparent relations to patches. The GPO change happened the Sunday before patch Tuesday and the error was not detected until after the patches as part of our usual post patch testing which made it appear to be related to the patches. 


    eburch@lasertel.com


    • Marked as answer by EWB_2 Tuesday, October 30, 2018 12:09 AM
    • Edited by EWB_2 Tuesday, October 30, 2018 12:11 AM
    Tuesday, October 30, 2018 12:09 AM
  • Hi,
    Thank you for your update and sharing. I’m very glad that the issue has been solved.
     
    As always, if there is any issue in future, we warmly welcome you to post in this forum again. We are happy to assist you!
     
    Best Regards,
    Daisy Zhou


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Thursday, November 1, 2018 7:42 AM