SCDPM Scripting: Trouble with LastRecoveryPoint

By YellowOnline on Thursday 29 March 2012 14:22 - Comments (4)
Category: SCDPM, Views: 1.602

Many a DPM admin who scripts in Powershell will want to create a script at one point that asks from a specific data source its last recovery point. For this, a data source object has the property ($DataSource).LatestRecoveryPoint.

Many a DPM admin will have been utterly disappointed to find out that the value returned is 01/01/0001 00:00:00.


I was one of those DPM admins and it took me three days - in between other work of course - to find out what the problem is. For a proper explanation and a (slightly more complicated) solution, I happily refer to Ruud Baars: Why good scripts may start to fail on you for instance with timestamps like "01/01/0001 00:00:00".

The short explanation: the properties are computed asynchronous and its value has a big chance of still being 0 when we call it.

My solution is to wait until the value is no longer 0, in other words: when the property has been properly filled in. To avoid endless loops, I also provided a time out.

As usual, I use the C# flexer for PoSh code.


C#:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
$Counter = 0
$Incremental = 1
$Timeout = 10
While($DataSource.LatestRecoverypoint -EQ 0)
    {
    Start-Sleep $Incremental
    $Counter = $Counter + $Incremental
    If ($Counter -GT $Timeout)
        {
        Write-Warning "Timed out."
        Break;
        }
    }
#Once the code gets here, out of the while-loop, you can really use the property.


A time-out seems to happen for machines who have never had a successful recovery point. You can easily use this information in your reporting (because that's probably why you need this snippet anyway).

This problem of asynchronous computing is not limited to this property nor to DPM, so the solution isn't either. I hope I could help someone with it.

Volgende: Fuck you Google 04-'12 Fuck you Google
Volgende: Eentje voor TheDailyWTF 02-'12 Eentje voor TheDailyWTF

Comments



By Tweakers user YellowOnline, Thursday 29 March 2012 18:58

Slechte copy/paste :) Goed gezien, heb het toegevoegd.

By Tweakers user siepeltjuh, Thursday 29 March 2012 20:27

Hoewel ik begrijp dat de code het minst relevant is en het concept m.b.t. de timeout belangrijker is, is door de afhandeling van de timeout (break) op regel 14 je property nog steeds niet 100% zeker gevuld.

By Tweakers user YellowOnline, Thursday 29 March 2012 20:34

siepeltjuh wrote on Thursday 29 March 2012 @ 20:27:
Hoewel ik begrijp dat de code het minst relevant is en het concept m.b.t. de timeout belangrijker is, is door de afhandeling van de timeout (break) op regel 14 je property nog steeds niet 100% zeker gevuld.
Sterker: de property is zeker en vast nog niet ingevuld. En zal het ook nooit zijn.

Ik heb de time-out op 10 seconden gezet omdat in mijn omgeving de respons steeds op minder dan een seconde was voor de andere objecten met deze property. 10 seconden is dus al veel marge. Als er na 10 seconden nog geen waarde doorgegeven is kan je besluiten dat er geen waarde is. En ook dat is relevante informatie.

Zoals gezegd: dit gebeurt klaarblijkelijk wanneer er nog nooit een succesfull recovery point aangemaakt is. Als dat het geval is, dan is het onmogelijk dat die property ooit een andere waarde dan 0 krijgt. Bij de break is je property dus ingevuld voor 100% zeker met de defaultwaarde 0. :)

[Comment edited on Thursday 29 March 2012 20:35]


Comments are closed