7

This is really annoying error - Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed., which I get every time I start powershell when outside company's network.

A screenshot

The bug

A short description:

I have a notebook in domain. There are two ways I'm using it. First is inside company's network and there everything works fine. Second way is when I'm outside the office, connecting via VPN. It produces above mentioned error every time I start powershell.

Script to search for the drive:

From my re-search of the error the cause appears to be un-connectable drive or resource.

I have tried to find out what could be the cause. Since there were some changes to the home folder structure I suspected it.

I have executed on both locations this script:

Write-Verbose -Message 'Get-PSDrive -PSProvider FileSystem' -verbose
echo 'Get-PSDrive -PSProvider FileSystem' | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log
Get-PSDrive -PSProvider FileSystem | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log

Write-Verbose -Message 'net use' -verbose 
echo 'net use' | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log
net use | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log

Write-Verbose -Message '[System.IO.DriveInfo]::GetDrives() | Format-Table' -verbose
echo '[System.IO.DriveInfo]::GetDrives() | Format-Table' | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log

[System.IO.DriveInfo]::GetDrives() | Format-Table | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log

# does not work properly
# Write-Verbose -Message 'Get-CimInstance -ClassName Win32_LogicalDisk -ComputerName $env:COMPUTERNAME' -verbose | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log
#Get-CimInstance -Class Win32_LogicalDisk | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log

Write-Verbose -Message 'Get-CimInstance -Class Win32_NetworkConnection' -verbose 
echo 'Get-CimInstance -Class Win32_NetworkConnection' | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log
Get-CimInstance -Class Win32_NetworkConnection | Out-File -Append -Encoding "UTF8" -FilePath filesystem.log

Results:

There appears to be U:\ lurking from shadows (does not appear when on premises). That is the network drive that was disconnected and should not be used anymore. (there is some legacy programs using it and it should be applied via GPO rules)

net use produces:

U:        \\server_name\U_login_name$   NFS Network

[System.IO.DriveInfo]::GetDrives() | Format-Table produces:

Name            DriveType DriveFormat       IsReady AvailableFre TotalFreeSpa   TotalSize RootDirecto VolumeLabel
                                                          eSpace           ce             ry                     
----            --------- -----------       ------- ------------ ------------   --------- ----------- -----------
C:\                 Fixed NTFS                 True   1779298304   1779298304 ...43488000 C:\         OSDisk     
U:\               Network                     False                                       U:\  

Get-CimInstance -Class Win32_NetworkConnection

LocalName                    RemoteName                   ConnectionState             Status                     
---------                    ----------                   ---------------             ------                     

U:                           \\server_name\U_login_name$      Disconnected                Unavailable                

On the other hand, when on company's network directly there is no U:\ what so ever.

What I have tried to rectify the situation

  • manual disconnect

    1) the ordinary way (right clicking on disconnect) an error is produced This network connection does not exist

    2) when using NFS umount u: :

    Disconnecting           U:      \\server_name\U_login$
    There are open files and/or incomplete directory searches pending on the connection.
    
    Do you want to continue this operation? (Y/N) [N]:y
    
    Network Error - 2250    Not Connected
    

    3) Tried forceful disconnect of all NFS mounts (U: drive is reported as NFS share) umount -f -a:

    Network Error - 2250    Not Connected
    
  • suggestions found on internet:

    1) Change GPO

    To resolve this issue, apply the following setting via group policy:

    User Configuration/Administrative Templates/System/Scripts/Run logon scripts synchronously = Enabled

(note: the computer starts really, really slow when using roaming profile. Had to disable this setting)

2) Mapped drive won't go away

I had really high hopes for this link Mapped drive won't go away - keeps reconnecting on logon I have same feeling as in the post - to quote:

>  I have indeed checked scripts and GPOs and this is nowhere to be found there. This looks more like a manual mapping that had the
> "Reconnect on logon" checkbox checked and is now so persistent that
> there was no "normal" way to undo it.

Unfortunately, every suggestion there failed.

  • registry

    1) I have searched for the string in the registry and found it here:

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2]. I tried to delete the U: drive key, but it keeps coming back.

2) I have also found it here (but did not experiment with it yet; I don't want to break the OS):

    Windows Registry Editor Version 5.00

    [HKEY_USERS\S-1-5-21-119559289-1840127793-336618761-855951\Volatile Environment]
    "HOMEDRIVE"="U:"
    "LOGONSERVER"="\\\\logon_server"
    "USERDNSDOMAIN"="dns_domain"
    "USERDOMAIN"="user_domain"
    "USERNAME"="login"
    "USERPROFILE"="C:\\Users\\login"
    "HOMEPATH"="\\"
    "HOMESHARE"="\\\\server_name\\U_login$"
    "APPDATA"="C:\\Users\\login\\AppData\\Roaming"
    "LOCALAPPDATA"="C:\\Users\\login\\AppData\\Local"
    "USERDOMAIN_ROAMINGPROFILE"="user_domain"

    [HKEY_USERS\S-1-5-21-119559289-1840127793-336618761-855951\Volatile Environment\1]
    "SESSIONNAME"="Console"
    "CLIENTNAME"=""

For now I have concluded that something is wrong with my roaming profile. I have to yet find the reason why the roaming profile is not updated with correct information.

Does anyone have idea/experience how to fix such an issue?

1 Answer 1

2

Finally, I hope to know the reason and tested some scenarios.

First, let me state that this is a Windows NFS BUG.

I don't know how to report it to Microsoft as mere mortal. I'll be reporting it here and on my blog.

There are conditions to be met for this error to propagate:

1) The computer must be in domain

2) You have to use this computer both on internal network and full-fledged VPN and you have to both on the same profile

3) You have to have the Microsoft's NFS implementation installed (alias Client for NFS)

4) You have to have the service started automatically at the start of the computer. If the service is on manual start and is started after the boot sequence is complete the bug will not manifest itself.

5) You have to have some kind of NFS share. The issue here is that the NFS share takes precedence over ordinary net use share. If you disconnect a NFS share and then map it using net use ... /persistent:yes, then this share will get overwritten after a reboot. It will be identified, after reboot, as NFS share again, and producing the error.

How to deal with it?

In short: Set the NFS Client for Windows service to manual from automatic mode. Use Task Scheduler or gpedit in conjunction with my powershell scripts for mounting and unmounting NFS shares. DO NOT stop NFS Client for Windows service when some shares are mounted!

Longer answer:

When using my scripts please read the bellow information:

Notes && best practices (important to read!):

A) NFS mount, at least the Microsoft's implementation, is NOT persistent over boots.  To overcome 
  this you have these options:                                                                    
  I) Schedule this script in Task scheduler under "ordinary" user e.g. DOMAIN\user and have the   
     check-box "Run with highest privileges" (in order to start the NFS Client service if stopped)
 II) Run it in the "Local Group Policy Editor" (gpedit.msc) under "Windows Settings\Scripts"      
     (Startup -> mount and Shutdown -> unmount) in the sections "Computer Configuration" (for all 
      users) or under "User configuration" (for one specific user)                                

B) Do !!!NOT!!! mount NFS drive on system-wide account as "nt authority\system".  At the first    
   glance this seems to be a good idea.  Don't be fooled, it is not!  When you mount NFS share    
   under "SYSTEM" account it will appear as fixed drive for all other users!  On "SYSTEM" account 
   it still will show as network share.  If you stop the NFS Client for Windows service, NOT      
   recommended when any NFS share active, and then start it again, then even under "SYSTEM"       
   account it will appear as "fixed" drive.  It will leave user no option other than restart for  
   unmount.                                                                                       

C) It is NOT a good idea to stop Client for NFS Service when you have NFS mounted.  It can lead   
   to unexpected states like the NFS share actually becoming a hard-drive for windows till reboot.

D) If the Client for NFS Service is started already then it is better not to stop it manually as  
   it can, under certain circumstances, refuse to start.  It is better to have a log-off script   
   take care of the unmount && stopping the service                                               

Errors or server configuration notes:

A) You are getting a powershell error:                                                            
   "Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider      
   failed."                                                                                       
   This error can be caused the NFS Client for Windows when service is starting with start of the 
   Windows.  It takes precedence over "ordinary" `net use` and it causes powershell to check      
   "FileSystem".                                                                                  

Ad A) Solution: Use this script for mounting NFS Share - set it using gpedit policies on start or
you can run via Task scheduler (It tries to start the Client for NFS service) - the script has to have rights to do so Don't forget to set the service "Client for NFS"("NfsClnt")
to manual start so it won't start with the windows startup.

B) If you are getting this error message (at your NFS server):                                    
   "(rpc.mountd[7243]: refused mount request from 192.168.XX.XX for <mount>: illegal port 24784"  
      you are most probably trying to connect on port over 1024.  To connect to NFS share you need
      to have 'insecure' option at your /etc/exports (if missing fix it and run `exportfs -r`)    

TIP: The mounting script requires UAC to start the service, if the service is not started already. You can:

1) run it manually - you will see UAC window                                                      
2) create a new Task in Task Scheduler and check the check box "Run it with highest privileges"   
3) create a startup powershell script in the local policies

Migration from the NFS OR windows share network drive (e.g. using off-line windows functionality) to cloud

Deleting the network drive (in my case an U: drive)

This issue can arise when you have your off-line files functionality switched on and the files are backup to a network drive. If your company changes that in favor of going to some cloud service, it can bring you a deadlock situation in your profile, when some application still need that previous network drive, but you still need to switch to to new cloud provider.

If you are using a NFS Client for windows from Microsoft this is how you get rid of the previous network drive:

As Got rid of the U: drive (not yet the message) with following steps:

1) Go to -> Start Menu\Programs\Administrative Tools\Services for Network File System (NFS)

2) Stop client for NFS with right-clicking on the item and selecting stop service

3) The simple manual removal works!!!!

net use u: /delete
--> U: was deleted successfully.

For the windows to forget the previous drive and correctly set the Volatile Environment to the new configuration you have to reboot.

Getting rid of the error message: Attempting to perform the InitializeDefaultDrives operation on the 'FileSystem' provider failed.

The error message does not appear with the Client for NFS stopped. It is enough to have it in state manual and start it via script

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .