Author Posts

May 10, 2016 at 6:37 am

I'm running the below script:

#Set the files

$originalfilehash = "\\Servername\C$\Windows\system32\file.txt"
$recoveredfilehash = "C:\DR Test Recovery\file.txt"

#Create the hash

$md5 = New-Object -TypeName System.Security.Cryptography.MD5CryptoServiceProvider
$originalfilehash = [System.BitConverter]::ToString($md5.ComputeHash([System.IO.File]::ReadAllBytes($originalfilehash)))
$recoveredfilehash = [System.BitConverter]::ToString($md5.ComputeHash([System.IO.File]::ReadAllBytes($recoveredfilehash)))

#Compare the files

if($originalfilehash -eq $recoveredfilehash) {"The file is consistent with the original"} Else {"Error: The file is NOT consistent with the original"}

My issue is the server that the originalfile is on requires credentials as it in another domain. I know I can use get-credentials but don't know how to add this to the script.

Any help?

May 10, 2016 at 6:42 am

It's "Get-Credential" :). Always a singular noun.

The easiest is probably to map a new drive using New-PSDrive, which for FileSystem can accept a credential. Or, map a drive the old-fashioned way using NET USE. That way, the drive itself is mapped using the credential, and you can perform whatever file operations you need.

May 10, 2016 at 6:47 am

That is going to work... I will map using the creds. set the file do the hash test and then blast the map away. Thanks

May 10, 2016 at 6:57 am

Hmm.

Well, you can define a [pscredential]$cred parameter in the script; if you make it Mandatory, it'll prompt for the credential if someone forgets to provide it proactively.

The problem is that you're reading the file using ReadAllBytes(), which simply doesn't provide a means of passing credentials. If you can't map a drive – even temporarily – then none of the .NET Framework methods are going to work. All of them are built on the assumption that a mapped drive will be available to hold the authentication channel. That's the case with all of the -Item and -ItemProperty commands in PowerShell, too – they don't accept credentials, because the underlying PSDrive is supposed to deal with that.

Mapping a drive using New-PSDrive _would_ work. You simply map it, perform your operation, and then unmap it. I do understand if you're not _allowed_ to do so for some reason, although that reason would be purely arbitrary and have nothing to do with the technology, or security, or whatever; mapping a drive is a native SMB operation. In fact, what you're already doing "maps" a phantom drive since all the Windows file I/O routines require a "drive" of some kind in order to run. The drive maintains the persistence handle for the SMB session.

Bear in mind that a PSDrive is not the same thing as a "network drive" in Explorer. You're not going to get a single-letter persistent network drive by default. A PSDrive is, by default, a PowerShell-only construct.

May 10, 2016 at 7:04 am

@Don

Always singular? Well, unless you're working with GPOs in Win7 vs 2012....

Cmdlet Set-GPPermission 1.0.0.0 GroupPolicy (2012)
Cmdlet Set-GPPermissions 1.0.0.0 GroupPolicy (Win 7)

I know, bad example with the GroupPolicy module...

May 10, 2016 at 7:27 am

Which they fixed in 2012 ;). Yeah, I know, people break the rules sometimes. But that makes them lawbreakers, not exemplars.