New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

xSQLServerRSConfig: Configurable URL reservations #570

Closed
bozho opened this Issue May 23, 2017 · 18 comments

Comments

Projects
None yet
2 participants
@bozho
Contributor

bozho commented May 23, 2017

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

This comment has been minimized.

Show comment
Hide comment
@johlju

johlju May 24, 2017

Collaborator

I labeled this as in progress.

Collaborator

johlju commented May 24, 2017

I labeled this as in progress.

@bozho

This comment has been minimized.

Show comment
Hide comment
@bozho

bozho May 31, 2017

Contributor

@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.

Contributor

bozho commented May 31, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@bozho

bozho May 31, 2017

Contributor

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 :-)

Contributor

bozho commented May 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@johlju

johlju May 31, 2017

Collaborator

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;
};
Collaborator

johlju commented May 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bozho

bozho May 31, 2017

Contributor

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.

Contributor

bozho commented May 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@johlju

johlju May 31, 2017

Collaborator

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/

Collaborator

johlju commented May 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bozho

bozho May 31, 2017

Contributor

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.

Contributor

bozho commented May 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@johlju

johlju May 31, 2017

Collaborator

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.

Collaborator

johlju commented May 31, 2017

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

This comment has been minimized.

Show comment
Hide comment
@johlju

johlju May 31, 2017

Collaborator

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

Collaborator

johlju commented May 31, 2017

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

@johlju

This comment has been minimized.

Show comment
Hide comment
@johlju

johlju May 31, 2017

Collaborator

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

Collaborator

johlju commented May 31, 2017

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

@bozho

This comment has been minimized.

Show comment
Hide comment
@bozho

bozho May 31, 2017

Contributor

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

Contributor

bozho commented May 31, 2017

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

@bozho

This comment has been minimized.

Show comment
Hide comment
@bozho

bozho Jun 1, 2017

Contributor

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.

Contributor

bozho commented Jun 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bozho

bozho Jun 1, 2017

Contributor

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)

Contributor

bozho commented Jun 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bozho

bozho Jun 1, 2017

Contributor

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?

Contributor

bozho commented Jun 1, 2017

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?

bozho added a commit to bozho/xSQLServer that referenced this issue Jun 1, 2017

@johlju

This comment has been minimized.

Show comment
Hide comment
@johlju

johlju Jun 1, 2017

Collaborator

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.

Collaborator

johlju commented Jun 1, 2017

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

This comment has been minimized.

Show comment
Hide comment
@bozho

bozho Jun 2, 2017

Contributor

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.

Contributor

bozho commented Jun 2, 2017

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.

@bozho bozho changed the title from xSQLServerRSConfig: Configurble URL reservations to xSQLServerRSConfig: Configurable URL reservations Jun 2, 2017

bozho added a commit to bozho/xSQLServer that referenced this issue Jun 2, 2017

@johlju

This comment has been minimized.

Show comment
Hide comment
@johlju

johlju Jun 4, 2017

Collaborator

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.

Collaborator

johlju commented Jun 4, 2017

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.

kewalaka added a commit to kewalaka/xSQLServer that referenced this issue Jun 4, 2017

bozho added a commit to bozho/xSQLServer that referenced this issue Jun 5, 2017

bozho added a commit to bozho/xSQLServer that referenced this issue Jun 6, 2017

bozho added a commit to bozho/xSQLServer that referenced this issue Sep 19, 2017

bozho added a commit to bozho/xSQLServer that referenced this issue Sep 19, 2017

bozho added a commit to bozho/xSQLServer that referenced this issue Sep 19, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

johlju added a commit to bozho/xSQLServer that referenced this issue Sep 22, 2017

@johlju johlju closed this in #638 Sep 22, 2017

johlju added a commit that referenced this issue Sep 22, 2017

xSQLServerRSConfig: Virtual directories and URL reservations (#638)
- Changes to xSQLServerRSConfig
  - Added support for configuring URL reservations and virtual directory names
    ([issue #570](#570))

@johlju johlju removed the in progress label Sep 22, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment