I always deployed from my local machine to Azure (Classic cloud service) but from yesterday I get this error:
Could not complete the request to remote agent URL 'https://[MYNAME].cloudapp.net:8172/msdeploy.axd?site=Default Web Site'.The request was aborted: Could not create SSL/TLS secure channel
The port is open. The web deploy is installed. As I see nothing has changed.
I tried to install a new version of Web Deploy (3.6) but it didn't help.
What else can be checked?
Thank you.
i faced the same problem: old 2008 r2 Server never changed anything
cause (speculation): since visual studio 15.9 they disabled SSL 2.0, TLS 1.0, etc. so it cant communicate propper with the old webdeploy
solution: enable TLS 1.2 on old webserver (and disable the old ones)
i found this link: https://developercommunity.visualstudio.com/content/problem/384634/webdeploy-netcore-api-to-iis-vs159.html
which linked to this blog:
https://tecadmin.net/enable-tls-on-windows-server-and-iis/
Step 1 – Backup Registry Settings We strongly recommend taking a
backup of the registry before making any changes. Use below link to
find steps to how to export registry values.
Step 2 – Enable TLS 1.2 on Windows You have two options to enable TLS
version on your system.
Option 1 – Merge Resistry File Download the Enable-TLS12-Windows.reg
and Enable-TLS12-TLS11-Windows.reg files on your Windows system. Now
right click on file and click Merge.
Step 3: restart.
PS: First i tried the "Client" way, which doesn't work for me. But maybe it helps some one:
I found the answer on this thread: https://stackoverflow.com/a/40050789/9624651
and he referenced to this link https://dougrathbone.com/blog/2016/02/28/pci-compliant-web-deploy-getting-webdeploy-working-after-disabling-insecure-ciphers-like-ssl-30-and-tls-10
Do have a look here. I guess they have mentioned your problem
Related
I'm trying to setup webdeploy on IIS8, but why am I getting 404 when accessing both https://[servername]:8172/msdeploy.axd and https://localhost:8172/msdeploy.axd locally.
I've installed management service.
I've installed webdeploy 3.5 using web platform installer. In Program and Features a changed the instalation of webdeploy to include all features including the handler.
In IIS Manager I've chosen Configure Web Deploy Publishing for default website's context menu.
I've restarted management service.
when i tried https://[servername]:8172/msdeploy.axd I was asked to enter credentials and accept the certificate. after that I got 404.
I've uninstalled webdeploy and installed using MSI manually including all features.
restarted entire server.
getting 404.
I don't believe you can open the service from a browser. I attempted that against a dev server that we deploy to many times a day and also received a 404. I would try deploying from VS instead as a test.
Also if anyone comes here and is using Visual Studio Publish dialog and the "Validate Connection" button fails: do NOT use the button when creating. Just click Ok, then Edit (in More actions menu).
In the Connection tab, click Validate Connection. This time it will asks you to accept an invalid certificate (since you likely self-signed it on your server). Accept it and the connection should go through.
I have recently been trying to migrate some websites from a 2003 server with IIS 6 to a 2012 server with IIS 8 installed. I am using Microsoft's Web Deploy tool and have been successful in copying a few web sites one at a time using the following command (changing the site identifier # for each site).NOTE: The reason the mumbo jumbo with replacing the drive exists is because our new server has a different data drive on it, and MSDeploy didn't like that. Could that be breaking things as well?
msdeploy -verb:sync -source:metakey=lm/w3svc/#,computername=SourceServerNameHere -dest:metakey=lm/w3svc/# -replace:objectName=metaProperty,scopeAttributeName=name,scopeAttributeValue=Path,targetAttributeName=value,match="F:",replace="E:" -enableLink:appPoolExtension > migration.log
The main issue is that when I try to navigate to any site one of three errors happens..
1. 503 Service Unavailable
2. 401.2 Unauthorized
3. 404.17 Not Found
These errors start from 1, and progress to 3 as I am trying to troubleshoot the IIS configurations. But this kind of defeats the purpose of using the Web Deploy Tool. Has anyone had any luck migrating sites being completely successful, or does the tool not actually support "IIS 6.0 or higher migration?"
Thanks in advance.
EDIT: So I have been able to get the main page of my site working by reverting the Handler Mappings and Default Documents to their parent configurations, and making sure that the AppPools don't conflict with versions, etc. The problem with this, is that I have to figure out how to do this for every app and app pool under the sites... Does anyone else have a similar problem?
Try using the iisApp provider instead of the MetaKey provider. For example,
msdeploy -verb:sync -source:iisApp=Site1/ContosoApp,computerName=Server1 -dest:iisApp="Site1/ContosoApp",computerName=Server2
https://technet.microsoft.com/en-us/library/dd569054(v=ws.10).aspx
I ended up contacting Microsoft Support to get this sorted out and ended up spending 3 hours on the phone with them...There were multiple issues that came up during the deploy tool's migration.
The bulk of the issues were corrected by changing the application pools to 64-bit and commenting out abomappercustom handlers in the applicationhost.config.
I recently purchased an SSL certificate for my website. I ran some tests with sslLabs.com and it gave a warning about two ciphers that are enabled: TLS_RSA_WITH_RC4_128_SHA and TLS_RSA_WITH_RC4_128_MD5. My website is on a shared server so I am not sure that they can disable these just for my website. I was wondering if there is any way to disable ciphers with the web.config file or a similar file that stores server properties? Thanks in advance! I am on a Windows Server using ColdFusion if that helps.
In my case I disabled the RC4 in the Microsoft Azure Cloud.
Basically I disabled it in my machine (Windows Registry) and then export that piece to a file.
Then you attach this file to your project and set the "Copy to Output Directory" to "Copy always".
Create a DisableRc4.cmd command file and attach it to the project as well with the copy always.
Add the following code into it:
#echo off
regedit.exe /s DisableRc4Cipher.reg
EXIT /B 0
In the end and in my case, it was just necessary to add it to the ServiceDefinition.csdef
Hope it helped after so long time.
Last week there was a blog post update which will disable RC4 cypher by default on cloud services. https://azure.microsoft.com/en-us/blog/azure-services-ssl-tls-cipher-suite-update-and-removal-of-rc4/
This update should be rolling out this month and if the operating system version is configured as automatic it will be automatically installed on the cloud service(see image below)
Next guest OS: WA-GUEST-OS-4.31_201604-01
Release date: May 2 2016
Operation system version configuration
I have a small solution that is composed out of 2 main projects a Mvc4 Web Api and a silverlight 5 Application. I've configured and deploy the application initially on the Azure platform and it all went great, but ever since when I deploy again the silverlight project does not get pushed and the online site has the old version.
I should mention all works great with the azure simulator on my local dev machine.
Anybody had a similar issue?
Regards,
I would suspect first (as Simon suggests) that the browser likely still has the previous client cached and loads that instead of downloading your new client.
You can use the version number in the code on your page that hosts the silverlight app to help. While it's easy for you to clear the cache - you don't really want to have to tell users to do that whenever you update.
Set the version to whatever your latest assembly version is (silverlight client project assembly), this will force the browser to download the client if the cached version is a lower number.
<param name="source" value="AppPath/App.xap?version=2.0.0.6"/>
Ok,
So after pulling my hair out, I finally figured out.
I have to change the build configuration to release in VS do a rebuild and then do publish because apparently the azure project does not do rebuild on the project when you publish it.
To solve this issue you'll need to identify the source of the problem (is it a client side problem where you have a caching issue or not). Even though you say caching isn't the problem we'll need to be sure about this first.
What I suggest is that you do the following first:
Activate Remote Desktop on your role
Connect through RDP and save this file to the role: http://support.microsoft.com/kb/841290 (fciv.exe)
Find the *.xap file (usually in E:\sitesroot) and get its checksum (using fciv.exe)
Modify the Silverlight project locally (maybe change a label or move around an element) to make sure its hash has changed.
Redeploy the application
Connect through RDP and use fciv.exe to get the checksum of the *.xap file once again
Compare both checksums
If the checksums are different, then it means that the deployment worked correctly and the Silverlight xap has been updated. If the checksum is the same, the problem lies with the deployment.
Please let us know the result so we can help you find the solution.
I am using a custom Api Token implementation using WCF Web API on Azure. This uses FormsAuthentication.Decrypt in order to obtain a FormsAuthenticationTicket. To make sure that the decrpyt process works across multiple instances, I have provided a MachineKey in my web.config.
However, I've noticed that the MachineKey doesn't seem to be working on Azure because it looks like Azure is using a random machinekey and overwriting the one I specificed in the web.config I'm using the latest Azure SDK 1.5 (or 1.6?)
I am well aware of this issue with Azure SDK 1.3 and I believe this was rectified in 1.4. Is there a chance that this issue has since re-appeared on Azure SDK1.5/1.6?
I was having the same problem where my FormsAuthentication tickets were not validating across sub domains after the recent Microsoft .Net 4.0 Security upgrade KB2656351.
My FormsAuth tickets are generated from my dedicated servers and read on sub domains on Windows Azure.
In order to get all sub domains to decrypt the tickets I made sure all my dedicated servers were patched with the latest .Net updates via Windows Update. Then I upgraded my Azure project to version 1.6 and selected the latest Azure OS after deploying. This seemed to do the trick.
Here are some articles about the issue:
http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx
http://technet.microsoft.com/en-us/security/bulletin/ms11-100.mspx
cheers
Francesco
Windows Azure already synchronizes machine keys across the same role in a deployment. As such, you should be fine to completely ignore the MachineKey setting in web.config and just let Windows Azure handle it for you (the web farm scenario is well supported). Your scenario is supported on Windows Azure out of box with no modifications (just call Decrypt).
The issue that you might be talking about was a 1.3 issue where the web.config files were being modified directly to sync the machine keys. This failed when the file was read-only (i.e. TFS source control) and caused deployment failures. That was fixed some time ago.
I think I finally found the solution. This had nothing to do with Azure or MachineKeys but had more to do with the way the app was being tested. The encrypted key that was stored on my Phone App was encrypted on a different web server (however, the machine key used was the same). I just un-installed and re-installed my app thereby forcing the server to generate a new key.
It seems that decrypting this key on a different server was causing problems. I'm a little worried if this will cause problems in the future. Shouldn't using the same Machine Keys ensure that encrypt/decrypt works across boxes?
Anyways, I apologize for the inconvenience caused.
We seem to have the same problem as well. We set machinekey set in the web.config file. Things were fine until a couple of days ago when Decrypt started returning null. The decryptionkey and validationkey are identical on all machines. Not sure what the problem is.
EDIT - Azure v1.6 does seem to respect the machinekey we set in the config file. We figured out how to solve our problem - Maybe this would help you - we were seeing that decrypt on the cookie does not work on our Windows 7 64 bit dev machines. Then we checked pending updates and there were a couple of .NET updates related to security. We ran the updates and voila things started to work again.
OK so I had the problem as described above in a 3-server NLB group.
It looks like the Windows Automatic Updates had installed KB2656352, KB2656358 and KB2657424 on two of the three servers.
I'd put money on the fact that it's because some of the servers are running with the patch and some aren't. I guess machines that have been patched don't like decoding things encoded by a non-patched machine (and/or vice-versa).
Anyway, I've installed all three patches on the remaining machine and put it back into the NLB group. It seems to all work fine.