locked
Azure Pack Websites/WebMatrix Publishing Defaults RRS feed

  • Question

  • It seems that the publishing defaults have changed between Azure Pack Websites V2 Update 2 and Update 6, before Update 6 WebMatrix would default to publishing through Web Deploy through the Publishing server. Now in Update 6, it defaults to publishing though Web Deploy on the Front End servers. How do I make Azure Pack Websites/WebMatrix default to using the Publishing server again?

    Thanks!

    Wednesday, July 15, 2015 1:53 PM

Answers

  • What you are saying is correct, but you still need a wildcard SSL cert to access the SCM site and any site over https without SSL errors (we generate a self-signed one by default). UR7 should address several bugs, and will take care of the publisher issue.

    Regardless, can you accept the proposed answer, as I believe it answers your original question?

    Please create separate threads for the other issues you have and we can address them on a case-by-case basis. We do take into account customer scenarios and forums conversations into for product planning.


    Software Engineer, Azure App Service

    Friday, July 17, 2015 7:16 PM

All replies

  • Also as a further consequence, the Web Deploy DNS Publishing setting appears to do nothing to change the actual Web Deploy URL in WebMatrix. It's like it's hardcoded to use the frontend SCM site URLs for publishing now.

    I much preferred the old way of publishing. How can I change this without having to downgrade?

    Thanks!



    • Edited by TxIceMan Wednesday, July 15, 2015 4:09 PM
    Wednesday, July 15, 2015 4:08 PM
  • Hi TxlceMan,

    Currently the global default is to use the SCM endpoint. To change on a per site basis, you can use the app setting:

    WEBSITE_WEBDEPLOY_USE_SCM = "false"

    Using the powershell on the controller machine, this can be done as follows:

    set-WebSitesSiteConfig -Name site -AppSettings 'WEBSITE_WEBDEPLOY_USE_SCM=false'

    Note that -AppSettings is a comma separated key value list. Using this command, you could set it for every site in your farm.

    We are fixing this in the next release, so that it can be configured for the whole farm.


    Software Engineer, Azure App Service




    Wednesday, July 15, 2015 5:53 PM
  • I think to not use the SCM endpoint, you need to set WEBSITE_WEBDEPLOY_USE_SCM = "false".

    I just tested this and I get this:

     Connection Error - Could not complete the request to remote agent URL 'https://<publisherurl>:8172/msdeploy.axd?site=sitename'.

    It's as though the publisher server isn't enabled.

    Will that be fixed as well in the next release as well? When is the next release coming out?

    Thanks!

    Wednesday, July 15, 2015 6:18 PM
  • UPDATE: I just ran a repair on my publisher boxes and it seems to work now.  Is there a way currently in powershell or editing the database to set that WEBSITE_WEBDEPLOY_USE_SCM value globally?

    Thanks for your help!


    • Edited by TxIceMan Wednesday, July 15, 2015 6:41 PM
    Wednesday, July 15, 2015 6:39 PM
  • Yes, WEBSITE_WEBDEPLOY_USE_SCM should be false.

    The connection error should not happen. Make sure that there are no network connectivity issues with your publisher and that it is enabled. Also check the websites management console. Also check that the publishing DNS is correctly set:

    (Get-WebSitesWebSystem ).PublishingDns

    The next version (v2u7) of Windows Azure Pack Websites is scheduled to come out on July 28.


    Software Engineer, Azure App Service


    Wednesday, July 15, 2015 6:47 PM
  • In Update 6 we don't offer a way to switch back to the previous publishing endpoint. In the upcoming Update 7 we will add this capability based on customer feedback.

    For now, I recommend to add the scm DNS mapping:

    Configure DNS mappings for the Web Sites Cloud


    During Web Sites Cloud setup, when configuring the Web Sites Controller, you will be prompted for the default domain name to be used for end user web sites.

    By default, web sites are created under a default domain. Once a web site is created, users can add custom domain names to each web site. While tenant web sites can be configured to support custom domains, Windows Azure Pack: Web Sites does not update custom DNS records. To ensure that all internet-facing web sites are configured with the appropriate IP address assignments, follow the guidance below.

    For a given domain such as Contoso.com, create the following DNS A records:

    Host name

    IP Address for

    *

    Front End Server(s)

    *.scm

    Front End Server(s)

    ftp

    Publishing Server(s)

    publish

    Publishing Server(s)

    This mapping scheme allows users to log on to both http://www.contoso.com and http://contoso.com to manage their sites. The Management Portal for Administrators and the Management Portal for Tenants are described in Deploy Windows Azure Pack for Windows Server.

    In the sample configuration above, user-created web sites are created using child domains such as site1.contoso.com, site2.contoso.com.

    When users publish content to their web sites via Web Deploy or FTP, they will use publish.contoso.com or ftp.contoso.com respectively. Content publishing via Git uses *.scm.contoso.com.

    System_CAPS_noteNote

    There is no requirement for a special domain for this deployment. You can use a subdomain like my.yourdomain.com under an existing domain.

    https://technet.microsoft.com/en-us/library/dn469319.aspx#BKMK_DNS

    Wednesday, July 15, 2015 8:15 PM
  • If site1.scm.contoso.com is going to be the default Azure Pack Websites publishing endpoint, then I would add to the documentation that if you plan on deploying using a source control product, the subscriber needs to create a 2 subject SSL certificate using site1.contoso.com and site1.scm.contoso.com. That would eliminate the need to use a wildcard certificate, right?

    Thursday, July 16, 2015 2:54 PM
  • No. site1 is the site name. In general the pattern for user created web sites is <site name>.<DNS suffix>. If you plan on having more than one site, you need a wildcard cert.

    Software Engineer, Azure App Service

    Thursday, July 16, 2015 6:06 PM
  • The first part of what you said is correct, however if the default deployment endpoint is going to be the source control endpoint, then that URL would be https://site1.scm.contoso.com or https://site2.scm.contoso.com and so on. That URL also requires SSL, which would necessitate having a wildcard certificate due to how the URL is setup. You could avoid that with a 2 subject SSL cert, but the subscriber would have to have knowledge of both site URLs.  Using the publishing server URL is the better way to do it as you completely avoid the security concerns that stem from wildcard SSL. I think this is where Azure Pack needs to depart from Azure. You can't expect or assume that organizations will use wildcard SSL in their Azure Pack environments for this like Microsoft did for azurewebsites.net.

    I'm definitely looking forward to UR7. Are there more bugfixes/new features upcoming worth mentioning? Will PHP 5.6 be available as an option? Are the bugs fixed with deployment slots?

    Friday, July 17, 2015 1:54 PM
  • What you are saying is correct, but you still need a wildcard SSL cert to access the SCM site and any site over https without SSL errors (we generate a self-signed one by default). UR7 should address several bugs, and will take care of the publisher issue.

    Regardless, can you accept the proposed answer, as I believe it answers your original question?

    Please create separate threads for the other issues you have and we can address them on a case-by-case basis. We do take into account customer scenarios and forums conversations into for product planning.


    Software Engineer, Azure App Service

    Friday, July 17, 2015 7:16 PM