Do you want to request a feature or report a bug?
Bug (apparently)
What is the current behavior?
I can successfully back up all subscriptions on a report server to an XML file using Export-RsSubscriptionXML.
I can then successfully restore all those subscriptions from the XML file, using Import-RsSubscriptionXML and Copy-RsSubscriptionwith a few exceptions: the problems seem to be subscriptions where Date/Time parameters have null values.
As a reminder, subscriptions can contain null parameters, as shown when setting up a subscription in the web interface:
So, here we have a Date/Time value being left null as a subscription parameter.
Such a null is stored in the ReportServer (SSRS 2022) database like this:
Note, this parameter only has a name, and value/label are not even mentioned in the definition.
In the exported XML file, the situation looks fairly similar - 'value' and 'label' tags are present, but self-closing, i.e. empty.
When we load the subscriptions from XML using Import-RsSubscriptionXml and copy them to the (new) server with Copy-RsSubscription all seems OK, until it reaches a report with this kind of null. At that point we get an error:
Error occurred while creating subscription xxxxxxx because: Exception calling "CreateSubscription" with "6" argument(s): "The value provided for the report parameter 'Month' is not valid for its type.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem.
Create a subscription that has a Date/Time parameter which is null.
Create an XML file with:
Get-RsSubscription -Proxy $YourProxyHere -Path / | Export-RsSubscriptionXml "C:\Temp\TestXML.xml"
This works until it encounters one of these nulls, then fails with the error mentioned above. "The value provided for the report parameter 'xxxx' is not valid for its type"
What is the expected behavior?
It should "just work" - i.e. the null should be identified as an acceptable value and the subscription should be created with the null parameter in place.
Which versions of Powershell and which OS are affected by this issue? Did this work in previous versions of our scripts?
Unknown if it used to work in previous versions. I am using:
Windows Server 2016 Standard (10.0.14393)
PowerShell 5.1 (5.1.14393.5582)
latest release of ReportingServicesTools (0.0.7.7)
Do you want to request a feature or report a bug? Bug (apparently)
What is the current behavior? I can successfully back up all subscriptions on a report server to an XML file using Export-RsSubscriptionXML. I can then successfully restore all those subscriptions from the XML file, using Import-RsSubscriptionXML and Copy-RsSubscription with a few exceptions: the problems seem to be subscriptions where Date/Time parameters have null values.
As a reminder, subscriptions can contain null parameters, as shown when setting up a subscription in the web interface: So, here we have a Date/Time value being left null as a subscription parameter.
Such a null is stored in the ReportServer (SSRS 2022) database like this: Note, this parameter only has a name, and value/label are not even mentioned in the definition.
In the exported XML file, the situation looks fairly similar - 'value' and 'label' tags are present, but self-closing, i.e. empty.
When we load the subscriptions from XML using Import-RsSubscriptionXml and copy them to the (new) server with Copy-RsSubscription all seems OK, until it reaches a report with this kind of null. At that point we get an error:
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Create a subscription that has a Date/Time parameter which is null.
Create an XML file with:
Get-RsSubscription -Proxy $YourProxyHere -Path / | Export-RsSubscriptionXml "C:\Temp\TestXML.xml"
Restore and load the file with:
This works until it encounters one of these nulls, then fails with the error mentioned above. "The value provided for the report parameter 'xxxx' is not valid for its type"
What is the expected behavior? It should "just work" - i.e. the null should be identified as an acceptable value and the subscription should be created with the null parameter in place.
Which versions of Powershell and which OS are affected by this issue? Did this work in previous versions of our scripts? Unknown if it used to work in previous versions. I am using: