I have 2 web sites in my Azure account and I would like to access the second one via FTP, however, when I load up the FTP site I am getting the FTP area for the first site and I cannot see any data for my second site.
My first site is a straightforward web site, but the second is an Orchard template. I was expecting to see the Orchard folder structure when I accessed the FTP area but seems only the first site is accessible via FTP.
I have looked at other threads about setting up your own FTP but I would like to avoid doing that until it is absolutely necessary.
So my question: Does anyone know if the Orchard website, generated by Azure, is accessible via FTP, or to get access can I safely reset the credentials from the dashboard on the second website so it has its own FTP area via an individual set of credentials?
I believe the username you use for FTP should be <web site name>\<username>, so you should already have different credentials for the two sites. Can you confirm you're using the right credentials to try to access the Orchard site? Check the "deployment user" on the right-hand side in the portal and make sure you're using that.
Related
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
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
I've made an FTP site through IIS using the DNS Name I was given when I signed up, but I want to set up multiple FTP sites on the same virtual server. How can I do this?
Also, the one FTP site I set up can't be connected to through anything other than an FTP client - I can't connect via IE / Chrome or Windows Explorer.
There is no multiple FTP account support for Azure App Service (formerly known as Azure Websites)
I am able to use IE to FTP to my site. what error do you see? Make sure you enter your credential and not login as anonymous user.
I'm trying to simply run a local website which has sime basic HTML files using IIS.
Through the IIS Manager I have created a new website and have set the physical path to the directory with the HTML files.
However when I input the physical path I get the following warning:
The server is configured to use pass-through authentication with a
built-in account to access the specified physical path. However, IIS
Manager cannot verify whether the built-in account has access. Make
sure that the application pool identity has Read access to the
physical path. If this server is joined to a domain, and the
application pool identity is NetworkService or LocalSystem, verify
that \$ has Read access to the physical path.
Then test these settings again.
Now, when I navigate to the site through localhost I get the following Unauthorized error:
You do not have permission to view this directory or page because of
the access control list (ACL) configuration or encryption settings for
this resource on the Web server.
What's going on here? When I right click my folder I seem to have given access to everyone. I haven't made any specific IIS changes so what could be the issue here?
EDIT:
MAN I cannot believe this. My case is so simple (I just wanna display some HTML files on localhost) which should require ZERO configuration at all. Yet IIS fails to meet the demand.
EDIT: I think everyone should have permission to my folder. Here's a picture of the permissions screen for the folder:
Working with a set of server protocols is different than adding files to a share. In this case, you're going to want to open IIS and navigate to the website you added it as.
There, you'll see a variety of icons, some under the heading of ASP.NET, some under IIS. The first heading you'll see under IIS is Authentication. That's the one you want. If this is strictly internal/for learning, go ahead and enable Anonymous Authentication. It's not safe, but it'll get you in the right place to start googling around.
We have been running WSS 3.0 for our intranet. We are going to be moving our internet site to WSS 3.0. The vast majority of people will access the new internet site anonymously. My question is in regards to the few people who will need to authenticate so that they can access intranet material from the internet.
We are going to host the intranet and internet sites on the same server. WSS 3.0 has already been installed, updated, and configured for our intranet. What would be the best way to set up the internet site collection so that it can be accessed anonymously but also so that when a user authenticates they can access intranet content as well? Currently the only way to access the intranet is to be on the companies domain with credentials that have access to it. What we would like to do, if possible, is use the login form that is built into WSS to make access to intranet content available opposed to setting up a sub domain.
You may use SharePoint alternte mapping feature as described in this article.
Configuring Multiple Authentication Mechanisms with Alternate Access Mappings in Windows SharePoint Services 3.0
I'm assuming that your Internet site collection and intranet site collection are not the same site collection with what I'm about to write. I am assuming, however, that they are housed in the same web application. If that's the case (and I understand enough of the specifics), here's how you'd carry out what you're trying to do:
Establish a Web application to house your site collections. You've already taken care of this (since you have your site collections available to you internally). In setting up a Web application, it (by default) is exposed at a URL (or server:port) through the Default zone mapping. For our purposes here, we'll assume that this is the URL through which you want to access the site internally (on your Intranet).
In order to expose your site collections via the Internet, you're going to want to extend the Web Application housing them. This is done through Central Admininstration > Application Management > Create or Extend Web Application. In extending the Web Application, you're creating another IIS site with (ideally) a publicly-accessible URL that can be exposed to the Internet. You'll be asked to pick a zone as part of the process; given your needs, I'd go with "Internet."
At this point, the Internet zone (you just extended) is still setup to use Windows authentication and Active Directory as it's membership provider. Though you probably want to keep AD as a membership provider (based on what you've stated), you'll probably want to look at enabling Forms-Based Authentication (FBA) on your Internet zone. Microsoft has a video on that here: http://technet.microsoft.com/en-us/windowsserver/sharepoint/dd355701.aspx. Note: you won't want to use the SQL membership provider if you intend to continue using Active Directory accounts. Instead, you'll have to wire-in the Active Directory Membership Provider for FBA. Some info on that can be found here: http://blogs.msdn.com/solutions/archive/2007/08/27/forms-based-authentication-fba-in-wss-3-0-moss-2007.aspx.
At this point, your Default zone site should use NTLM and an intranet-available URL. Your Internet zone site should use FBA and have an Internet-available URL. You'll need to enable anonymous access on your public site collection for the Internet zone. This is done through a combination of Central Administration changes and changes from within the site collection itself (http://www.mindsharpblogs.com/ben/archive/2007/02/11/1557.aspx). Important point: when going into the site collection to enable anonymous access, be sure to go through the Internet URL; don't go through the default zone (i.e., the intranet zone).
With all of these things in-place and your site collections (or more specifically, the IIS site servicing the Internet zone Web application) wired-up to the outside world, you should be good to go.
I made a number of assumptions as I wrote this, so you may (obviously) need to adjust. Setting up anonymous access isn't overly hard, but there are a lot of steps to it. If you hit hiccups along the way, don't be afraid to search for answers. Many folks have done it successfully ... but more often than not, there are challenges along the way.
Good luck!
You can also create a web application for your intranet use, so user's who are in the domain get access through an internal URL authenticated, and then extend that web application for the extranet application for anonymous users....