Quantcast
Channel: File Services and Storage Forum
Viewing all articles
Browse latest Browse all 1766

Some servers are unable to access a network share from within

$
0
0

I have an entirely Windows Server 2008R2 environment consisting of 13 servers.  All servers are joined in an Active Directory domain.  I have recently written the below script to automate the process of doing weekly backups, using the built in windows server backup.  For troubleshooting purposes, I am running this command with full domain administrator permissions, and I have tried running this from an elevated powershell prompt as well.  When running the following script, I get this error about some computers. Ignore the warnings about EFI volumes not being able to be backed up and the error about all volumes not being able to be backed up.

WARNING: The file system of volume EFI System Partition is not NTFS. Only NTFS-formatted volumes can be added to the
backup policy.
PSComputerName     : SERVERNAME
RunspaceId         : abecd970-f1cb-4e49-bc71-4e48fce71b52
PSShowComputerName : True
VolumeLabel        :
MountPath          : C:
MountPoint         : \\?\Volume{ba7cbe56-10b7-4e67-8234-97030bf37ee6}
FileSystem         : NTFS
Property           : Critical, ValidSource
FreeSpace          : 110962745344
TotalSpace         : 145758355456

PSComputerName     : SERVERNAME
RunspaceId         : abecd970-f1cb-4e49-bc71-4e48fce71b52
PSShowComputerName : True
VolumeLabel        : Data
MountPath          : E:
MountPoint         : \\?\Volume{421c99c2-1ce0-4b33-b123-19143130b373}
FileSystem         : NTFS
Property           : Critical, ValidSource
FreeSpace          : 291198238720
TotalSpace         : 291862740992

WARNING: Not all volumes that you specified were added to the policy.
WARNING: The backed up data cannot be securely protected at this destination. Backups stored on a remote shared folder
might be accessible by other people on the network. You should only save your backups to a location where you trust the
 other users who have access to the location or on a network that has additional security precautions in place.
PSComputerName         : SERVERNAME
RunspaceId             : abecd970-f1cb-4e49-bc71-4e48fce71b52
PSShowComputerName     : True
Label                  :
WBDisk                 :
WBVolume               :
Path                   : \\BACKUPSERVER.WORKPLACE.LOCAL\ServerBackups
TargetType             : Network
InheritAcl             : True
PreserveExistingBackup : False

Starting Backup for SERVERNAME
The credentials entered are either incorrect or do not have write permissions to the remote shared folder. Please speci
fy valid credentials.
    + CategoryInfo          : NotSpecified: (:) [Start-WBBackup], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.Windows.ServerBackup.Commands.StartWBBackup

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

$ServersToBackup = "SERVER1", "SERVER2", "ETC"

function BackupComputer()
{
    if ( (Get-PSSnapin -Name Windows.ServerBackup -ErrorAction SilentlyContinue) -eq $null )
        {
            Add-PsSnapin Windows.ServerBackup
        }

#Files server
$Nas = "\\BACKUPSERVER.WORKPLACE.LOCAL"
#Root folder
$HomeBkpDir = ($Nas+"\ServerBackups")

$currentpolicy = get-wbpolicy
$WBPolicy = New-WBPolicy
Add-WbSystemState -Policy $WBPolicy
Add-WbVolume -Policy $WBPolicy -Volume $currentpolicy.volumestobackup
Add-WBBareMetalRecovery -Policy $WBPolicy
Set-WBVssBackupOptions -Policy $WBPolicy -VssFullBackup
$BackupLocation = New-WBBackupTarget -network $HomeBkpDir
Add-WbBackupTarget -Policy $WBPolicy -target $backuplocation
Write-Host -nonewline 'Starting Backup for '; get-content env:computername
Start-WBBackup -Policy $WBPolicy
}

Invoke-Command -computername $serverstobackup -ScriptBlock ${function:BackupComputer}
BackupComputer

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Now, the account I am using to try to run the backup has full permissions to access the share.  Computer accounts also have access to the share.  If I physically login, I am able to access the shares where the backups are stored without any issues.  I'm clueless why this script works for some computers, but not others.  I have linked to a photo of a wireshark capture of the traffic between the backup server and a server trying to run a backup as well.  I don't think UAC is the issue, as the computers that can run it are not using UAC.  I don't think it's issues with SMB signing, as the the policy's appear to be the same on servers that can or cannot backup. 

http://i.imgur.com/efAvV.png

With the exception of 1 server, the ones that can run this backup script were installed more recently.  A previous consulting company did work where I am, and appeared to have no clue what they were doing.  I know a Windows Update (not sure which one), caused a domain controller to continuously BSOD until they restored it.  There was only one domain controller before this incident, and after this incident another domain controller was added.  For whatever reason, this consulting company also decided to promote just about every other server to a domain controller at one point in time.  I know there was some underlying Kerberos authentication issues that they fixed as well.

I have used FQDN's and non FQDN's as well.  I have some belief that the failing servers may be trying to use NTLMv2 authentication with null accounts, and not Kerberos, as this behavior is described here.  http://blogs.technet.com/b/nettracer/archive/2010/06/17/null-credentials-migh-be-used-when-accessing-remote-systems-from-a-process-running-under-local-system-account-context.aspx

Thanks,

Chris




Viewing all articles
Browse latest Browse all 1766

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>