I have about 6 different Azure websites all on the same subscription.
When I look at the FTP deployment address they all have the same address (ftp://waws-prod-ml1-001.ftp.azurewebsites.windows.net) but different usernames/passwords.
The problem is that at least using Windows explorer there appears to be NO way to access a second deployment once it's already remembered that I've connected to a previous one. I've tried editing the address to include the username (ftp://username:password#wasa....) but no luck, I've tried shutting down all explorer windows, clearing the credential cache etc. etc, but no dice - it still keeps connecting to whichever one I first authenticated with at least since I last logged into Windows.
Does this basically mean I'll have to use a different FTP client that doesn't cache credentials like this? Bit surprised I can't find any forum posts suggesting other people haven't had this issue.
You can always right click in Windows Explorer and choose Login As option which will allow you to use a different set of credentials.
To understand how FTP credentials work for Azure App Service, check out Azure same FTP url for all azure websites sharing same appservice plan
Related
My domain was previously hosted in another place (some years ago) and was connected to Azure. Some days ago I successfully changed the dns to a different hosting company but it seems I still get a webpage related to Azure when I try to access the website on my browsere. This is what is displayed:
Error 404 - Web app not found.
The web app you have attempted to reach is not available in this Microsoft Azure App Service region. This could be due to one of several reasons:
The web app owner has registered a custom domain to point to the Microsoft Azure App Service, but has not yet configured Azure to recognize it. Click here to read more.
The web app owner has moved the web app to a different region, but the DNS cache is still directing to the old IP Address that was used in the previous region. Click here to read more.
btw. I clicked the links and they are not helpful.
I have no idea how Azure works, but I have access to the login information. When I log in on portal.azure.com everything seems to be empty, there are no apps, only a canceled subscription and really nothing to see.
If I click "All resources", I get "No resources to display".
My first thought is that this is some kind of a cache problem, but I have cleared the cache in my browsers, tried different ISP and different computers in different continents, but I always get the same error message.
If I check whois.com and who.is I can see that the new dns is correct and the only thing that should be displaying is the temporary index.html page that is currently in the htdocs folder for the new host.
Do you know what I need to do to remove any connection to Azure and display my new website?
It's solved.
I just needed to edit my dns entries. For some reason, they were still pointing to an old IP.
I created few web applications for the one app service plan. For all these apps I am seeing one FTP url. Issue is that when I go to the URL, I can see one "Site/wwwroot" folder which only shows one application.
Isn't is possible to access FTP of other web applications?
All applications works fine. I don't understand how this FTP is being created. If it's showing just one application in FTP, what criteria is based on that? I am seeing the 1st application based on the alphabetical order.
The FTP Url is same for all the sites in a stamp and will be same even if you create multiple app hosting plans as long as the hosting plans are in the same stamp. A stamp is a collection of servers and roles in a particular datacenter.
So how azure connects to the right site - the distinction here happens when you provide the user name for the site that you are trying to connect. The user name has the form sitename\$sitename when using publish credentials and has the form sitename\username when using deployment credentials and this name is used by app service to identify which site you are connecting to.
http://weblogs.asp.net/bleroy/azure-web-sites-ftp-credentials has more details.
Also read https://github.com/projectkudu/kudu/wiki/Deployment-credentials to understand difference between the two kind of credentials.
So just specify credentials in this way and you can connect to your sites using ftp.
Hope this helps
We're currently having an issue where when someone tries to access our TFS server via Visual Studio, they're hit with an Error TF30063: You are not authorized to access
The TFS server is on a different domain to what the client machines trying to connect are on. There is a domain trust between the two and other shared resources work fine.
I have found that it does temporarily work if you open up an RDP (remote) connection to the server in the background and login using your local domain credentials. After leaving your remote session connected and trying to connect again via Visual Studio, it works fine.
Another thing to point out which indeed would be related is, looking at the Administrator group permissions on the TFS server it does not resolve the usernames of the users in the list until they initiate an RDP connection atleast once after a reboot has occurred. Instead it shows their SID.
Things I’ve tried so far are;
Adding Windows and Generic Credentials to the Credential Manager on the TFS server for their domain accounts. I thought it might be an issue with the server not caching their credentials which meant an RDP connection needed to exist each time.
Enabling Windows Authentication in IIS
Adding the path to Trusted Sites in Internet Options
Enabling Network access: Allow anonymous SID/Name translation in Group Policy for the machine.
Creating a registry key under HKLM\System\CurrentControlSet\Control\Lsa called TurnOffAnonymouseBlock and set to 1 which essential is what the GP above does.
None of these however have seemed to fix the issue.
Any suggestions would be greatly appreciated!
If there is a domain trust in place, you should just add the users AD account that they log into their machine with, as a valid user in TFS.
For example, if TFS is in Domain A, and the user's laptop is in domain B (and they login to their laptop with a domain B account), then you need to ensure that Domain A trusts Domain B (either a two-way trust, or one way with A trusting B). Then you just need to make sure to add the user's domain B account as a TFS Contributor for example, and they should be able to access TFS without doing anything special.
Using the new interface for Windows Azure, how do I enable RDP? I am using a cloud service and my site is mysite.cloudapp.net. In my publish settings, I enabled RDP. Where do I find my RDP credentials? How do I enable FTP, if possible? Here are the instructions that I followed:
https://www.windowsazure.com/en-us/develop/net/common-tasks/remote-desktop/
I see no hosted services tab in the new layout.
When I try to RDP, I receive an instant failure message that I cannot connect. I am using Windows 8 and I tried Windows 7.
For RDP, assuming you've followed all the steps and the configuration is right, you need to use the management portal, click on cloud services on the left and select the service whose instance you want to RDP into, select instances in the menu at the top and then pick the instance you want to RDP into.
The bottom toolbar should include a connect option, clicking on it should download an RDP file you can open to RDP into the machine, this will prompt you for the credentials you need to provide (as provided in your project configuration).
You can actually save this RDP file and re-use it for the deployment, but it may become invalid if you re-deploy as port numbers change.
As for FTP, much has been written about it, for example this, but you really need to consider the note in this article, for example - files you upload to the role instance will disappear if the role needs to be recycled for whatever reason.
IIS5 is running on SERVER1.
One of the virtual directories in IIS, myfiles, is pointing to "A shared location on another computer", //SERVER2/myfilesshare
When I try to access the page:
http://SERVER1/myfiles
... I get the error:
You are not authorized to view this page
HTTP 401.1 - Unauthorized: Logon Failed
Internet Information Services
I have triple-checked the "Connect As..." settings in IIS. The credentials I'm using to access the share are correct-- they work when connect to the share in Windows Explorer, but not through the IIS virtual directory.
I've tried granting full permission to Everyone on the folder in SERVER2, but no luck.
Any thoughts?
This was how I solved my problem, might help you.
By default, IIS uses local user called IUSR for virtual directories when using anonymous authentication. It does not use application identity, which should be obvious, if you use procmon.
How can you force it to use application identity?
Easy, under IIS manager:
1) go to Authentication
2) Edit "Anonymous authentication"
3) Select "Application pool identity"
4) Restart IIS & it should work.
The same accomplished with PS: Set-WebConfigurationProperty -filter /system.WebServer/security/authentication/AnonymousAuthentication -name username -value ""
This link contains the pros/cons: http://blogs.technet.com/b/tristank/archive/2011/12/22/iusr-vs-application-pool-identity-why-use-either.aspx
Permission issues can be tricky. Try running filemon on the 'other computer' It can be downloaded over here: http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx
(it's not a big application just a tiny lightweight tool)
After you've started filemon, stop the monitor process (I believe it's turned on by default when you start the application), clear the logged data, create a filter for the folder you have trouble getting access to. Start the monitor process. Request your webpage. Stop the monitor process and look for "access denied" messages in filemon. When found, filemon will also mention the name of the actual user which is trying to get access. This might help you to get to a solution.
Btw when using Windows Server 2008 you will need processmon instead: http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
Imagine a scenario where for whatever reason you want to have your IIS Server access a Share on a File server and they are not on the same domain.
If you can follow and get this to work for you (I have done it Win2008-R1 32-bit File Server and Win2008-R2 64-bit with IIS 7), then you should be in good shape for any scenario.
Same name local account on both servers with same password
On IIS, use aspnet_regiis -ga MyAccount to give local account access to IIS guts
Now use that as the Application Pool Identity of the Website
Using Local Security Policy (Admin Tools) enable trust for delegation for local account
Restart IIS server
On File Server, use Local Security Policy to enable access from network for local account
Create Share granting desired permissions to local account (also Security tab permissions as needed)
Open up File & Print Sharing ports on both (as restrictive as possible) to point where it works for you when you are using Windows Explorer between the two
Back to IIS, create Virtual Directory using UNC path to Shared folder from File Server
Just use Pass-through authentication (which would use your local account)
You can tell Anonymous Authentication setting of the Virtual Directory to use Application Pool Identity as well
Use something that will test/verify. The key really is trust for delegation using a Service Account (domain or otherwise), and having IIS use the account you want it to use instead of Local Server or Network Service.
This took me all day to figure out. Various threads in StackOverflow and other Internet sources helped point me to various resources me but didn't find my exact answer anywhere. Hopefully next person stuck with this problem will get a speed boost on the path to resolving with my description of what worked for me.
try enabling windows authentication on the virtual directory security tab (in IIS).