xSQLServerRSConfig: Configurable URL reservations

[bozho]

We have a need to alter the default SSRS URL reservations (change the port in our case).

We should probably aim for a general solution, that would allow us to add and remove URL reservations, including HTTPS ones, which would require being able to specify a relevant SSL certificate.

I'll add a .MOF schema changes suggestion as soon as I think of a good one :-)

[johlju]

I labeled this as in progress.

[bozho]

@johlju, here are my thoughts about this one...

I suggest the following change to the .MOF schema:

[ClassVersion("1.0.0.0"), FriendlyName("xSQLServerRSConfig")]
class MSFT_xSQLServerRSConfig : OMI_BaseResource
{
    [Key, Description("Name of the SQL Server Reporting Services instance to be configured.")] String InstanceName;
    [Required, Description("Name of the SQL Server to host the Reporting Service database.")] String RSSQLServer;
    [Required, Description("Name of the SQL Server instance to host the Reporting Service database.")] String RSSQLInstanceName;
==> [Write, Description("Report Server reserved URLs.")] String[] RSReservedURLs;
==> [Write, Description("Report Manager/Report Web App reserved URLs.")] String[] RMReservedURLs;
    [Read, Description("Is the Reporting Services instance initialized.")] Boolean IsInitialized;
};

To keep things (and code) simple, I suggest we don't support adding/removing individual URLs - the resource will make sure that only listed URLs are reserved.

If any of RSReservedURLs and RMReservedURLs is not specified, the resource will reserve the default (http://+:80)

What to do if either parameter is an empty array? Remove all reservations or also use defaults? I'd say remove reservations, but I'm not sure if there's a genuine need for that.

[bozho]

We could also support changing virtual directory names, which is a bit more involved. For $RSConfig.SetVirtualDirectory to succeed on an already initialised SSRS instance, it is necessary to first remove all URL reservations for a given application (report server or report manager), execute $RSConfig.SetVirtualDirectory and then re-add URL reservations. SSRS config GUI hides the complexity :-)

[johlju]

I would like to suggest that the name is changed for both parameter like below. Since 'RM' is no longer a term used, but the site is still named 'Reports' (so far in 2017 too). And also end the name with 'Url', singular since it can contain one or more.

If a parameter is empty or null, it should be enough to have ValidateNullOrEmpty() on the parameter to throw an error? In the README.md (and parameter description) it can say it is optional.

Shouldn't we add a parameter for thumbprint for the certificate to use, when using SSL? Suggest parameters below.

And I wouldn't mind that we support changing virtual directory names. README.md can explain what will happen. It sounds like it needs to remove everything and set it upp again (including certificate).

Let me know what you think. 😄

[ClassVersion("1.0.0.0"), FriendlyName("xSQLServerRSConfig")]
class MSFT_xSQLServerRSConfig : OMI_BaseResource
{
    [Key, Description("Name of the SQL Server Reporting Services instance to be configured.")] String InstanceName;
    [Required, Description("Name of the SQL Server to host the Reporting Service database.")] String RSSQLServer;
    [Required, Description("Name of the SQL Server instance to host the Reporting Service database.")] String RSSQLInstanceName;
==> [Write, Description("Report Server reserved URLs.")] String[] ReportServerReservedUrl;
==> [Write, Description("Report Manager/Report Web App reserved URLs.")] String[] ReportsReservedUrl;
==> [Write, Description("The thumbprint for the certificate to bind to the Report Server web site.")] String ReportServerSslThumbprint;
==> [Write, Description("The thumbprint for the certificate to bind to the Report Manager/Report Web App web site.")] String ReportsSslThumbprint;
    [Read, Description("Is the Reporting Services instance initialized.")] Boolean IsInitialized;
};

[bozho]

I was also thinking about adding support for handling SSL certificate bindings as well, but I feel SSRS approach is a bit lacking...

Using either GUI or WMI, you can only bind an SSL certificate to an IP:PORT, not HOSTNAME:PORT.

What we actually do when we need to expose SSRS, we create a regular SSL HOSTNAME:PORT binding in IIS (something like <machine fqdn>:443, as we'll usually have an accompanying website) and only add SSRS URL reservations (e.g. https://<machine fqdn>:443/Reports)

These URLs will not show up in SSRS configuration GUI, but it works just fine.

[johlju]

I think we need to use the WMI here (or preferably CIM). The other method you suggest sound like unsupported?

The configuration settings will appear in the file only after you use the Reporting Services Configuration tool or the Report Server Windows Management Instrumentation (WMI) provider to bind a certificate.
https://msdn.microsoft.com/en-us/library/ms345223(v=sql.100).aspx

Binding it to 0.0.0.0 would mean all NIC's. Would that be good enough for starters?
But should not hard code 443. I think that should be a parameter as well, what do you think?
And 1033 (language) is already set in the resource, so that can be reused here as well.

$result = $serverClass.CreateSSLCertificateBinding('ReportServerWebService', '‎e9b993f5a5101bf9bea71896ffc07118b9ca2dcc', '0.0.0.0', 443, 1033)  

From this article.

https://ruiromanoblog.wordpress.com/2010/05/08/configure-reporting-services-ssl-binding-with-wmi-powershell/

[bozho]

I agree with the parameter name change, it reads better.

I'll add support for virtual directories, too. Shouldn't be a problem.

The issue I have with SSL cert binding is that you can only do it on IP:PORT, not HOSTNAME:PORT. If you're running a website alongside an SSRS instance and you plan to use the standard 443 port, you will probably already have an SSL binding for the website on HOSTNAME:443. You don't actually need (I don't remember if you even can have) a separate SSL binding on 0.0.0.0:443 in that case.

On the other hand, we can add support for SSL bindings, but keep it decoupled from URL reservations, so that users have the flexibility when registering SSRS to be used over HTTPS.

[johlju]

It seems that it is possible to use IIS to configure URL's (see below). But then IIS have to be installed and configured which I feel is not part of this resource. But can be a prerequisites for a boolean parameter that says UseInternetInformationServicesForBindings (not the best name) which if set to $true tries to register bindings using IIS.

Though, to start somewhere, I think we have to assume that if the thumbprints are assigned then WMI will be used (assume no IIS). But if there is no thumbprints assigned, then we can assume the user wants to configure the bindings them self. Does that sound like a way to do it?

SSL bindings are a shared resource in Microsoft Windows. Changes made by Reporting Services Configuration Manager or other tools like IIS Manager can impact other applications on the same computer. It is a best practice to use the same tool to edit bindings that you used to create the bindings. For example if you created SSL bindings using Configuration Manager, then it is recommended you use Configuration Manager to manage the life-cycle of the bindings. If you use IIS manager to create bindings, then it is recommended you use IIS manager to manage the life-cycle of the bindings. If IIS is installed on the computer before Reporting Services is installed, it is a good practice to review the SSL configuration in IIS before configuring Reporting Services.
https://docs.microsoft.com/en-us/sql/reporting-services/security/configure-ssl-connections-on-a-native-mode-report-server

With a gotcha also when removing SSL. Don't know if this is related to WMI/CIM also.

If you remove SSL bindings for Reporting Services using the Reporting Services Configuration Manager, SSL may no longer work for Web sites on a server that is running Internet Information Services (IIS) or on another HTTP.SYS server. Reporting Services Configuration Manager removes the following registry key. When this registry key is removed, the SSL binding for IIS is also removed. Without this binding, SSL is not provided for the HTTPS protocol.

[johlju]

And keeping them decoupled from URL Reservations sounds like a plan.

[johlju]

This will deprecate resource xSQLServerRSSecureConnectionLevel, right? See issue #587.

[bozho]

Yeah, I agree. We can add an optional parameter for setting SecureConnectionLevel to xSQLServerRSConfig

[bozho]

Regarding SSL bindings, I don't think we need UseInternetInformationServicesForBindings parameter. If you've created correct bindings in IIS, all you need to do in SSRS is create appropriate URL reservations (and not specify SSL-binding parameters)

We only need optional SSL-binding parameters not related to the URL reservations parameters, and we need two of each: "IP:PORT" string and SSL cert thumbprint.

[bozho]

Ok, I've implemented the URL parameter name change and added virtual directory parameters.

The only scenario the code currently doesn't cover is if you want to revert virtual directory names to defaults without explicitly specifying them, since not specifying the parameters means "leave the settings as they are". I don't think that's a huge issue.

I've added some verbose messaging.

I need to do a bit more testing, since initialisation failed at one point, possibly due to a timeout (still need to replicate it)

[bozho]

On second thought, the way I've currently implemented virtual directories and URL reservations, we get different behaviours for uninitialized and initialized SSRS instances.

If an instance has not been initialized, empty values mean "initialize with default values".

If an instance has been initialized, empty values currently mean "don't change the values, whatever they are".

I think it would be better if empty values for virtual directories and URL reservations mean "use default values" - this would give us consistent behaviour.

What do you think?

[johlju]

How do you know what the default values are? How do you set the default values? Do you have to hard code those names into the resource? If so, then we could set the default names as default values to the parameters maybe?

Either way I agree that we should have a consistent behavior. If possible, if a user wants to set a value thru other means than DSC, we should not change that. But in this case, these are so close together, so not setting URL Reservation and virtual directory before initializing seems wrong. And would a user use this resource if the user has already initialized the reporting services? If the user is using this resource on an already initilized reporting service it could set it to the default values I think. But again, if the user just want to use the resource to bind an certificate to the reporting services, then we should not touch any other setting that the user has not provided.

So I think how the resource is implemented right now might be the right approach. But I want to think this one over :)

Hope I make sense.

[bozho]

Default virtual directory names are ReportServer and Reports for the default instance name. That's how SQL Reporting Services Configuration GUI sets them, and it's in MS's documentation.

For named instances, the default values are ReportServer_$InstanceName and Reports_$InstanceName. That's recommended in MS documentation and I assume SQL Reporting Services Configuration GUI will use them, too, but I can't test it right now.

These default values are also used in the current xSQLServerRSConfig code.

Regarding the virtual directory parameters, having slept on it, I agree that the current approach is a better one. If the parameters are not specified, the user is basically saying "I don't care about them". That allows them to configure other stuff (e.g. URL reservations and SSL bindings) and not affect virtual directory names if they were configured in any other way.

RS initialisation without explicit virtual directory name parameters will simply use defaults, which is the current resource behaviour (without the parameters) and corresponds to initialising RS using the configuration GUI.

[johlju]

When installing SQL2016 and SQL2017 Reporting Services named instances I got ReportServer_$InstanceName and Reports_$InstanceName. So since that is default using the resource, it must be default using GUI too.

I agree with you regarding virtual directories.