You need to change some configurations for the website to work with Azure. If you do not change them, the assets are stored locally, and will not properly deploy to the Azure BLOB storage.
The attribute container for the BLOB provider and topic for event provider should be unique per site, within the same storage or service bus account. This means that you need to update the mapping for BLOBs and event providers.
- In Visual Studio, open web.config and add the following configuration under the episerver.framework section:
<blob defaultProvider="azureblobs"> <providers> <add name="azureblobs" type="EPiServer.Azure.Blobs.AzureBlobProvider,EPiServer.Azure" connectionStringName="EPiServerAzureBlobs" container="mysitemedia"/> </providers> </blob> <event defaultProvider="azureevents"> <providers> <add name="azureevents" type="EPiServer.Azure.Events.AzureEventProvider,EPiServer.Azure" connectionStringName="EPiServerAzureEvents" topic="MySiteEvents"/> </providers> </event>
- Compile the solution. Your local site displays an error message because the site is pointing to Azure after the configuration changes. This is corrected when you publish the project to Azure.
- Developers have access to the Azure portal, and can find all the details they need to use AzCopy to upload the BLOBs to Azure BLOB Storage. If you need help, zip the BLOBs and upload them to a place as specified by the Episerver Managed Services team. (The BLOB container should have been set up by Operations already, and the container connection string should already be in place on the Web App in Azure.) See Deploying to Azure Web Apps to understand the whole process.
Note: When you deploy a website, you may want settings in the deployed application's web.config to be different from your local development web.config. Instead of changing these settings for your local installation, you can apply a transformation of the web.config file when you deploy to Azure; that way, you can avoid breaking your local site. See How to transform web.config when deploying a web application project (MSDN).
You must have SSL for any of the CMS packages. (Commerce includes SSL by default.)
You need to create the web service end point on the app (for whatever the internal service requires).
DdsAdmin is not officially supported at DXC CMS 9. However, you can see some DDS data and source code at https://github.com/Geta/DdsAdmin.
Search Microsoft for How to use a client certificate in Azure. The article requires signing in to Developer.DE.
Incoming connections to the Web app is open for everyone. They can restrict access in web.config to certain IP addresses but that is only for requests that originates from the outside. Not return traffic to a request that the web app initiated.
Set certificationvalidationmode=”None” to get the client to work in Azure Web App. For more information, see Nine simple steps to enable X.509 certificates on WCF. See also the X509CertificateValidator class.
There are issues with client certificates in Azure Web Apps because of how they are designed and environment restrictions. An Azure Web App does not have permission to modify the Trusted Root store or any other store than the Personal(My) store for the CurrentUser, which is where the certificate is stored that is uploaded through the Azure Portal. This is because a certificate added to Trusted Root would be trusted for all other Web Apps running on the same server. A certificate must be issued by an issuer that already has their certificate installed in Trusted Root store or that you do not validate it.
However I replied back and asking if they at least can look into the possibility to grant access to Trusted People store for CurrentUser as that wouldn’t affect all Web Apps and you can move an uploaded certificate from My store to any other during startup of the application with a bit of C# code. This way it would be possible to use certificationvalidationmode=”PeerTrust”.
The following sample code copies a through-portal-uploaded certificate to Trusted People store for the CurrentUser:
var myStore = new X509Store(StoreName.My, StoreLocation.CurrentUser); myStore.Open(OpenFlags.ReadOnly); var peopleStore = new X509Store(StoreName.TrustedPeople, StoreLocation.CurrentUser); var cert = myStore.Certificates.Find(X509FindType.FindBySubjectName, "<subjectofcerttobecopied>",false).OfType<X509Certificate2>().First(); peopleStore.Open(OpenFlags.ReadWrite); peopleStore.Add(cert);
New Relic shows errors such as the following:
The file '<filepath>' does not exist.
Cause: If an incoming URL domain is not entered as a hostname under the website, a “does not exist” error may occur. For example, suppose that periodic requests are sent to http://<customernnnnnprod.azurewebsites.net>/link/43F936C99B234EA397B261C538AD07C9.aspx. If there is no hostname <customernnnnnprod.azurewebsites.net> defined, an error occurs.
Resolution: Using the Manage Websites feature, select the applicable website then add a wildcard hostname. Ensure the selected Culture and Type values, for example:
The incoming request to <customernnnnnprod.azurewebsites.net> is redirected to the primary website, and the “does not exist” error does not occur.
For more information, seeAdding and updating a website from admin in the Managing websites chapter of the Episerver user guide.