Is it possible to monitor Distributed File System Replication (DFS-R) with PRTG? How can I achieve this?
How can I monitor Distributed File System Replication (DFS-R)?
Votes:
0
15 Replies
Votes:
1
Monitoring Distributed File System Replication (DFS-R)
Just thought I'd share a small and simple VBScript that you can use to monitor file replication using Windows DFS-R. This VBScript will write a small text file on one server of the DFS namespace and then monitor another server/path location for that same file to appear. You specify the paths using the parameters in PRTG.
- It will keep checking for the replicated file every second for 60 seconds.
- It will report the number of seconds it took to replicate back to PRTG.
- It will report if the replicated file was found or not.
The number of seconds before timeout is configurable.
The script measures replication in only one direction, but you can create two sensors using this same script. Reverse the paths in the PRTG parameters field of the sensor settings so that each sensor measures replication in the opposite direction.
Prerequisites
Open a text editor and copy the Test-DFS-R.vbs script (see below) into it. Save it with this name and place the file in the \Custom Sensors\EXE subfolder of your PRTG installation (see this article how to find PRTG folders).
Change the PRTG Probe Service so that it runs using an account that has permissions to the root administrative drive shares of the servers where you need to measure replication. For example, the account will need to have permission to
- ServerName1\C$ and
- ServerName2\C$.
Replace C$ with the administrative share of the drive that contains the replicated folder.
Sensor Settings
Following the PRTG settings are listed for the EXE/Script Sensor:
- EXE/Script: Select Test-DFS-R.vbs from the list.
- Parameters: "server1\AdminShare\folder" "server2\AdminShare\folder"
The parameters define the folder paths to the two servers you want to check separated by a space. Enclose each path in quotes. You cannot use the DFS namespace path here. Use only the path from the administrative share of the hard drive that it is on. Example: ServerName\D$\Users - Security Context: Use security context of probe service.
- Timeout (Sec.): Use 90 or more depending on the timeout value in the script.
- Channel Name: Enter a name for the channel, for example, Replication Time.
- Unit String: The unit of the returning values is seconds.
- Scanning Interval: Use 5 minutes or longer. Do not use 60 seconds as this is too short.
Script
See below for the Test-DFS-R.vbs script:
Set ArgObj = wscript.Arguments strDFSPath1 = ArgObj(0) strDFSPath2 = ArgObj(1) i = 0 ' Modify the value for intSecondsToWait for the timeout value of this script intSecondsToWait = 60 ' Build strings for testing the DFS paths strTime = Cstr(Timer) 'Convert number of seconds since midnight to string strPath1 = strDFSPath1 & "\TestDFS-R-" & strTime & ".txt" strPath2 = strDFSPath2 & "\TestDFS-R-" & strTime & ".txt" Set objFSO = CreateObject("Scripting.FileSystemObject") ' Check if both paths exist If objFSO.FolderExists(strDFSPath1) Then ' MsgBox "The path exists!" Else WScript.Echo "Path one doesn't exist or no permission to access this path!" WScript.Quit(1) End If If objFSO.FolderExists(strDFSPath2) Then ' MsgBox "The path exists!" Else WScript.Echo "Path two doesn't exist!" WScript.Quit(1) End If Set objTextFile = objFSO.CreateTextFile(strPath1, True) ' Write a date and time stamp to the test file. strText = Date & Time objTextFile.Write ("This file is safe to delete. Timestamp: " & strText) objTextFile.Close ' Check if file exists in the second path every second for 60 seconds, then clean up. For i = 1 To intSecondsToWait If objFSO.FileExists(strPath2) Then WScript.Echo i & ":OK" objFSO.DeleteFile(strPath1) WScript.Quit(0) End If WScript.Sleep 1000 Next ' WScript.Echo "Replication failed. The test file does not exist in both paths." objFSO.DeleteFile(strPath1) WScript.Echo "DFS DOWN!" WScript.Quit(1)
Created on Apr 11, 2013 7:31:21 PM
Last change on Apr 12, 2013 11:09:07 AM by
Gerald Schoch [Paessler Support]
Votes:
0
Cheers Nick, this is exactly what I need to do. But I can't get it to work ... message is "Path one doesn't exist or no permission to access this path".
Probe account is a Domain Admin (for testing), and has full permissions to the paths. Parameters are entered as "filesrv01\f$\Work\DVC" "filesrv02\f$\Work\DVC". Source and destination folders are accessible from the probe PC using the parameter as a UNC path ...
filesrv01\f$\Work\DVC and
filesrv02\f$\Work\DVC.
Any ideas where I'm going wrong?
Votes:
0
Thanks Nick, after some trial and error I worked out that the parameters have to be UNC paths, so using "
filesrv01\F$\Work\DRC" "
filesrv02\F$\Work\DRC" works fine.
Many thanks for this great script.
Votes:
0
What exactly was the parameter string that you passed in to get it to work? I've tried "server01\m$\folder" "server02\m$\folder" and seemingly every combination that I can think of and it's still not working in PRTG. It works just fine from the command line with the PRTG account. Any help would be greatly appreciated!
Votes:
0
Try "
server01\m$\folder" "
server02\m$\folder" with Windows Credentionals
Votes:
0
Question? what would be the path VBScript writes the text file too?
Votes:
0
Hi, big thanks for this script.
It is so easy and simple. Works on W2K8R2 and With W2K12R2 DFS Systems.
Votes:
0
I'm getting an error: "Response not wellformed: "(C:\Program Files (x86)\PRTG Network Monitor\custom sensors\EXE\Test-DFS-R.vbs(2, 1) Microsoft VBScript runtime error: Subscript out of range )" (code: PE132)"
Has anyone seen this before?
Votes:
0
I'm getting the Error: "Response not wellformed: "(Path one doesn't exist or no permission to access this path! )" (Code: PE132)
Can anybody help?
did you wrote the Parameters in the Parameter field of that Test or in the Script? I tried some combinations but not any work :(
Votes:
1
I was getting "Response not wellformed: "(Path one doesn't exist or no permission to access this path! )" (Code: PE132)
I entered in the UNC Path like this "
servername\share" and it works perfectly. Needed the double backslash.
Votes:
0
Thanks a million for this! It's working very well except it's not always deleting the text file from the folder. So I still kind of have to manually monitor the replicated folder in case things get out of hand.
Votes:
0
I have just come here to say, that this website isnt showing the blackslash
so you need to have \ \server\path\etc
Votes:
0
Awesome script, thanks for sharing. Once I'd figured out the PRTG website is hiding the double slashes on the UNC path :-)
This is working for me, but it's always reporting 6 seconds (5.1 - 5.2secs execution time) although I can see by monitoring the DFS folders that replication is much quicker than this - less than a second to replicate then a few seconds before the files are deleted. The delete also replicates almost instantly.
There seems to be a delay between the replication occurring and the script recognising this and deleting the file.
Has anyone else come across this?
Tim
Edit - having let these sensors run over the weekend, sometimes I see spikes of 11 seconds, it's usually 6 seconds, so it seems to be reporting in blocks of 5 seconds + 1. Looking at the script I can't see why it would be doing this.
Created on Oct 16, 2015 4:20:24 PM
Last change on Oct 19, 2015 3:18:51 PM by
Torsten Lindner [Paessler Support]
Votes:
0
@Tim: I'm afraid we have not seen such behaviour ourselves, so I'm afraid we have to wait if possibly on of the other users reports back.
Votes:
1
Confirming the comments section here are stripping the leading "backslash-backslash" from the UNC paths mentioned here, just make sure your parameters are well formed UNC paths and you should be fine.
@Tim Boothby, I had the exact same experience and what I think is happening here is a function of the time it's taking PRTG to actually execute the script. I ran the same sensor on a fresh, relatively unused probe server and I am getting a consistent 1s replication time on that probe for the exact same servers. I think a busy Probe server just artificially extends the time it takes to execute. Not really a problem, as I'm only wanting to know if there's a true problem with DFS-R, but I would like to know why it seems to take PRTG an excessively long time to run basic scripts which normally take a few seconds.
I even re-wrote the original poster's script using powershell to see if there was a notable difference and it still takes 5-6 seconds even though DFS-R is basically handling things nearly instantly. Please note, if you use this, it's formatted to return data via an 'EXE/Custom Script Advanced' sensor.
#Parameters should be two UNC paths to DFS servers replicated directories: "\\SERVERNAME01\D$\DFS_ShareName" "\\SERVERNAME02\D$\DFS_ShareName" PARAM ($PATH1, $PATH2) #establish constants, modify as necissary $secondstotimeout = 90 #Seconds to wait for replication before giving up (can be longer than error threshold) $secondstoerror = 60 #Seconds to wait before setting sensor to error $secondstowarn = 45 #Seconds to wait before setting sensor to warning #Create unique timestamped filename $UnixSeconds = (Get-Date -UFormat "%s").ToString().Split('.')[0] #Establish UNC paths to the test files $FileName01 = $PATH1 + "\DFSR-TEST-$UnixSeconds.txt" $FileName02 = $PATH2 + "\DFSR-TEST-$UnixSeconds.txt" #Create Test File New-Item $FileName01 -type file #Start the test provided we confirm both UNC paths exist first If ((Test-Path $PATH1) -and (Test-Path $PATH2)) { $ErrorState = 0 #Append a text string to the source text file Add-Content $FileName01 ("This file is safe to detlete. TimeStamp: " + (Get-Date)) #Check for changes made to source text file to appear in destination text file For ($i=1; $i -le $secondstotimeout; $i++) { If((Get-Content $FileName01 -ErrorAction SilentlyContinue) -eq (Get-Content $FileName02 -ErrorAction SilentlyContinue)){break} Else {Start-Sleep -s 1} } } Else {$ErrorState = 1} #If $SecondsToTimeout expired we want to note that as a sensor failure, not a limit excess. If ($i -ge $secondstotimeout){$ErrorState =1} #Format results into PRTG Friendly XML Return $s = @" <prtg> <Error>$ErrorState</Error> <result> <channel>Replication Time</channel> <unit>TimeSeconds</unit> <mode>Absolute</mode> <showChart>1</showChart> <showTable>1</showTable> <float>0</float> <LimitMaxWarning>$SecondsToWarn</LimitMaxWarning> <LimitMaxError>$secondstoerror</LimitMaxError> <LimitMode>1</LimitMode> <LimitWarningMsg>Replication Time in Excess of Warning Threshold!</LimitWarningMsg> <LimitErrorMsg>Replication Time Exceeds Error Limit!</LimitErrorMsg> <value>$i</value> </result> </prtg> "@; #clean up after ourselves by removing text file from source Remove-Item -path $FileName01 #return final result XML to PRTG Probe Sensor $s;
Add comment