![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[Quicklink]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
SCDPM Scripting: Trouble with LastRecoveryPoint
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.
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.
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 | $Counter = 0
|
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.
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.
04-'12 Fuck you Google
02-'12 Eentje voor TheDailyWTF
Comments
By
YellowOnline,
Thursday 29 March 2012 18:58
Slechte copy/paste
Goed gezien, heb het toegevoegd.
By
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
YellowOnline,
Thursday 29 March 2012 20:34
Sterker: de property is zeker en vast nog niet ingevuld. En zal het ook nooit zijn.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.
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]
In order to comment on this post you need to be logged in. Use this link to log in when you are already a registered user. If you don't have an account you can create one here.
