I am working on upgrading a project to Windows Azure 1.3 and I am running into an issue with hosting WCF services in an Internal Web Role. I get the following exception when trying to access the services:
HTTP could not register URL http://127.0.0.1:5111/service.svc/. Your process does not have access rights to this namespace
I did have a similar issue when working with Azure 1.0 and resolved it by with the following code:
new BasicHttpBinding() { HostNameComparisonMode = HostNameComparisonMode.Exact }
With this new issue, there seem to be a few common solutions; using the above code, runing the httpcfg tool to explictly change namespace reservation, and running as Administrator.
As far as I know, the httpcfg tool will not work for an Azure Internal WebRole because the port is dynamically assigned. Running Visual Studio as Administrator and debugging the Cloud project does not fix the problem either (Visual Studio does launch the Emulator).
It seems like the Azure Compute Emulator does not inherit the permissions from the Visual Studio process. Has anyone run into a similar problem, any ideas on fixes, work-arounds?
Karl
Okay, my suspisions were proved correct. When the Azure Compute Emeulator starts, it adds the Web Role instances in IIS, but the App Pool Identity does not have permissions to register namespaces.
I found this blog article which describes how to change the identity of the app pool when a Web Role instance is started.
http://www.wadewegner.com/2011/01/programmatically-changing-the-apppool-identity-in-a-windows-azure-web-role/
This is a less than ideal solution, but works.
Related
I have .Net Core 3.1 web api which is deployed to AKS. I have created Azure App Insights instance to write the logs.
I followed
https://learn.microsoft.com/en-us/azure/azure-monitor/app/asp-net-core?tabs=netcore6
to configure the .Net application.
Added Microsoft.ApplicationInsights Nuget package
Added connection string in appsettings
Added services.AddApplicationInsightsTelemetry(); in startup.cs
Running api from local pc I can see telemetry being logged in Visual Studio output.
But when I deployed to Azure nothing is flowing into App Insights. Absolutely nothing.
I am new to this and checked pod logs but dint find anything in it. The connection string is correct.
From my local pc I tried to write to Actual App Insights. But although I can see telemetry in Visual Studio nothing is going to Azure.
I am assuming because "Accept data ingestion from public networks not connected through a Private Link Scope" is false for the App Insight instance.So this is also not helping me to debug.I cannot change this setting.
The Azure account is linked to On Premise network.
Can someone point to me what could be the issue
Microsoft.ApplicationInsights.AspNetCore was not working when using Connection String. When I changed to InstrumentKey the logs started flowing. Weird as MSFT recommendation is to use connection string
I would like to achieve, with Web API, the following WCF behaviour:
Using Visual Studio 2015 create a brand new WCF Service Application. Build. Right away the sample service is "online" and can be accessed with a browser, Fiddler, etc. I do not need to explicitly run the project in VS for the services to be available to any client.
I'm completely new to Web API, and have not seen any documentation on how to achieve this same seamless deployment.
Anyone?
Instead of running the project in Visual Studio (which spins up an IIS Express instance), make sure the IIS feature is turned on on your windows installation, and setup a new site, and point it at the directory of your build output.
For a step-by-step see: http://www.c-sharpcorner.com/UploadFile/2b481f/how-to-host-Asp-Net-web-api-on-iis-server/
I am attempting to deploy a simple lightswitch application (HTML not Windows app) in VS 2013. I have selected to not have authentication to make the testing easier.
The IIS server and the database server are on different machines. I have followed the steps here for server setup.
However, when I go to the website after publishing, I get this error:
You do not have permission to view this directory or page.
I went to the IIS server and made sure that only Windows authentication was enabled on the application that was sent over. After reading another MS article on the 401 error, they recommended unchecking the Kernel Mode Authentication. That only prompted a username/password request, which did not work.
What am I doing wrong here? I assumed having no authentication setup in the deployment would make the website open to anyone on our network. Not the case?
Found the problem(s) with this one.
Problem #1
When I downloaded / installed Microsoft's Web Platform Installer on my IIS server, the LightSwitch application I was working on and several other seemingly random websites/apps in the IIS all had the Authentication settings disabled for every authentication type (Anon, Basic, Windows, Forms, etc.). Had to go and Enable windows authenication on several websites. Did not expect that...
Problem #2
HTML Client folder was not loaded on the machine for some reason. Removed Lightswitch app from IIS and deleted the folder. Created a package for install in VS2013 and then copied the zip file over to the IIS server. Flawless install after that... One thing to watch for it to change the default setting in IIS from 'default.htm' to 'default.aspx'.
We are trying to configure continuous integration with TFS 2012. While queuing a new build, the publish fails with the error:
Build FAILED.
"C:\src\ProjectName.sln" (default target) (1) ->
"C:\src\Website\ProjectName.csproj" (default target) (2) ->
(MSDeployPublish target) ->
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.targets(4377,5): msdeploy error ERROR_COULD_NOT_CONNECT_TO_REMOTESVC: Web deployment task failed. (Could not connect to the remote computer ("ServerName") using the specified process ("Web Management Service") because the server did not respond. Make sure that the process ("Web Management Service") is started on the remote computer. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_COULD_NOT_CONNECT_TO_REMOTESVC)**
I checked all the points mentioned in the IIS.NET documentation for this error. Both services mentioned, Web Management Service and Web Deployment Agent Service, are running fine. A restart of those services has no change in behavior.
Windows Server 2008 R2 with IIS 7.
Web Deployment Agent Service is running on port 8172.
Web Deploy 3.0
Windows Firewall is not blocking any port on the server.
How can this be fixed?
If you install Web Deploy 3.x BEFORE Web Management Tools are installed, you'll have to re-install Web Deploy. I beat my head against the wall for hours on this.
Install the Web Management Services ("Turn Windows Features On/Off"/Roles -> Web Server -> Management Tools -> Management Service)
Then uninstall Web Deploy (repair didn't work) via the usual Add/Remove Programs control panel
Install Web Deploy 3.x again using Web Platform Installer.
Fixed. /Sigh
Double check in your Web Deploy settings that the name of the website is exactly that of what's in IIS.
Ben Day blogged more about it.
Fix that i saw on another website:
Fix it by adding “http://” to server.
In other words, when server is www.xxxx.com would get the 403 error, but when server is http://www.xxxx.com, then it works.
You need also to indicate the app name e.g 'Default Web Site/MyApp'
That was my error. Once I added /MyApp, it worked.
I got this error when using msdeploy, not TFS. In my case I needed to make sure the user msdeploy is using had permission to deploy to the website.
Find the website in IIS manager, right click and go to Deploy, then Configure Web Deploy Publishing. Find the user used by Web Deploy and setup for this website.
In my case the Internet proxy was enabled on source - which made msdeploy to reach out to internet instead of local ICN.
You should check the logs on your IIS first - see that you actually get to the server, and then you can locate the exact error here - https://support.microsoft.com/en-us/help/943891/the-http-status-code-in-iis-7-0-iis-7-5-and-iis-8-0
Uninstalling and re-installing (not repairing!) after setting up IIS did most of the magic for me.
There is another possible cause of the error. IIS Managemente Service have its own configuration for IP Address Restrictions, which default value is Deny Access for unspecified clients (Windows Server 2012 R2 with IIS 8.5).
You must set this value to Allow or add access to your specific IP address/IP address range using the Allow... button.
Remember, you must Stop the Management Service previously to change this configuration.
Is there any way so IIS could connect to LocalDB without using the NT SERVICE\NETWORK SERVICE user account.
This account has not suitable permissions. I'm looking use some other default account or is there some way that I can use the NETWORK SERVICE account without changing permissions?
You should use Shared Instances feature of LocalDB. These two posts on Using LocalDB with Full IIS should give you more information. Especially the second part seems relevant, but the first one contains some context as well.
(note: the original links are no longer available, using archive.org instead)
Part 1: User Profile
Part 2: Instance Ownership
Original (non-working as of March 2019) links:
Part 1: User Profile
Part 2: Instance Ownership
In case the links disappear again, I am copy-pasting solutions from the article for easier access:
Post 1:
The problem we're facing is that the user profile needs to be loaded. That shouldn't be hard since each IIS Application Pool has an option called Load User Profile that can be found in Advanced Settings section. Unfortunately things got slightly more complicated in Service Pack 1 for Windows 7. As described in KB 2547655 enabling loadUserProfile is not enough to fully load user profile, we also need to enable setProfileEnvironment. This requires editing applicationHost.config file which is usually located in C:\Windows\System32\inetsrv\config. Following the instructions from KB 2547655 we should enable both flags for Application Pool ASP.NET v4.0, like this:
<add name="ASP.NET v4.0" autoStart="true" managedRuntimeVersion="v4.0" managedPipelineMode="Integrated">
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
</add>
Having completed that we restart the Application Pool to make sure the new settings are applied and run our Web Application again.
Note from my side: Just find "applicationPools" tag in that applicationHost file and update those two variables to true, so it looks like this:
<processModel identityType="ApplicationPoolIdentity" loadUserProfile="true" setProfileEnvironment="true" />
That's it, save the file and restart IIS pool.
Post 2:
The Problem of the Private Instance
As we can see we are facing the following error:
System.Data.SqlClient.SqlException: Cannot open database "OldFashionedDB" requested by the login. The login failed.
Login failed for user 'IIS APPPOOL\ASP.NET v4.0'.
This time the error is quite clear. LocalDB was started and the Web Application was able to connect to it, but the connection was then terminated due to login failure. The ApplicationPoolIdentity account for the IIS application pool (in this case IIS APPPOOL\ASP.NET v4.0) couldn't login to LocalDB instance because the database specified in the connection string (OldFashionedDB) wasn't found. How odd, since connecting from Visual Studio with the same connection string succeeds!
How is it possible that Visual Studio connects to LocalDB just fine, while the connection from Web Application fails? In both cases the connection string is the following:
Data Source=(localdb)\v11.0;Initial Catalog=OldFashionedDB;Integrated Security=True
The answer is that there are two different LocalDB instances here. Unlike SQL Server Express instances, which are running as Windows services, LocalDB instances are running as user processes. When different Windows users are connecting to LocalDB, they will end up with different LocalDB processes started for each of them. When we connect to (localdb)\v11.0 from Visual Studio, a LocalDB instance is started for us and runs as our Windows account. But when Web Application, running in IIS as ApplicationPoolIdentity, is connecting to LocalDB, another LocalDB instance is started for it and is running as ApplicationPoolIdentity! In effect, even though both Visual Studio and Web Application are using the same LocalDB connection string, they are connecting to different LocalDB instances. Obviously the database created from Visual Studio on our LocalDB instance will not be available in Web Application's LocalDB instance.
A good analogy to this is My Documents folder in Windows. Say we open Visual Studio and create a file in our My Documents folder. Then we login to the same machine as a different user and go to My Documents folder again. We won't find the file there as My Documents of the second user and our My Documents are two different folders. Similarly LocalDB instances (localdb)\v11.0 owned by two different users are two different processes with two different sets of databases.
This is also the reason the Web Application was able to connect to LocalDB from IIS Express. Just like LocalDB, IIS Express is a user process. It is started by Visual Studio and runs as the same Windows account as the Visual Studio process. Two different processes running as the same Windows account (Visual Studio and IIS Express, both running as our Windows account) connecting to (localdb)\v11.0 are connecting to the same LocalDB process, also started as the same Windows account.
Possible Solutions
Understanding the nature of the problem brings multiple approaches to solving it. As different approaches have different tradeoffs, instead of prescribing one solution, below I presented three approaches that seem most viable to me. My hope is to hear from you about the one that worked best for you! Here is the list:
Approach 1: Run IIS as our Windows user
Approach 2: Use LocalDB Shared Instance
Approach 3: Use full SQL Server Express
Let's take a closer look at each of them.
Approach 1: Run IIS as our Windows user
If different user accounts are the problem, why not try to run our Web Application under our Windows account? Web Application would connect to the same LocalDB as Visual Studio and everything should just work.
Making the configuration change is relatively easy, just start IIS Manager and find the right Application Pool:
Open Advanced Settings screen (available in the context menu):
Click the little button in the Identity property to bring up the Application Pool Identity screen:
Starting the Web Application again will confirm that the problem is solved:
What are the drawbacks of this approach? Of course running Web Application under our account brings certain security risks. If someone hijacks our Web Application they will be able to access all system resources our account can. Running the Web Application as ApplicationPoolIdentity provides additional protection since ApplicationPoolIdentity accounts have very limited access to local system resources. Therefore I cannot recommend this approach in general, but when used with care it is a viable option in some cases.
Approach 2: Use LocalDB Shared Instance
We could also use an instance sharing feature of LocalDB. It allows us to share a LocalDB instance with other users on the same machine. The shared instance will be accessible under a public name.
The easiest way of sharing an instance is to use SqlLocalDB.exe utility. Just start an administrative command line prompt, and type the following command:
sqllocaldb share v11.0 IIS_DB
It will share the private LocalDB instance v11.0 under the public name IIS_DB. All users on the machine will be able to connect to this instance, using (localdb).\IIS_DB as a server address. Note the . before the instance name, indicating this is a shared instance name. We should replace the connection string in our Web Application with an updated one:
Data Source=(localdb)\.\IIS_DB;Initial Catalog=OldFashionedDB;Integrated Security=True
Before the shared instance can be used by the Web Application we need to start it and create logins for the ApplicationPoolIdentity. Starting the instance is easy, simply connecting to it from SQL Server Object Explorer will start it and keep it alive. Once we are in the SQL Server Object Explorer we can also create the login for ApplicationPoolIdentity. We could use the following query:
create login [IIS APPPOOL\ASP.NET v4.0] from windows;
exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin
This script gives full administrative access to our LocalDB instance to the ApplicationPoolIdentity account. Whenever possible, I would recommend using more limited, database-level or even table-level permissions.
Now we can run our Web Application again. This time it should work just fine:
What are the drawbacks of this approach? The main one is that, before Web Application can connect to the shared instance, we need to make sure the instance is started. For that to happen the Windows account that owns the instance must connect to it and the connection must be kept open, or the LocalDB instance will shut down.
Approach 3: Use full SQL Server Express
Since full IIS runs as a service, maybe using traditional, service-based SQL Server Express is the right approach? We could just install SQL Server 2012 Express RC0 and create the OldFashionedDB database in it. We can even use our brand new SQL Server Data Tools to do it, as it works with any SQL Server version and edition. Our connection string would have to change to:
Data Source=.\SQLEXPRESS;Initial Catalog=OldFashionedDB;Integrated Security=True
Of course, just as in the previous case, we would need to make sure the ApplicationPoolIdentity account has access to our SQL Server Express instance. We can use the same script as previously:
create login [IIS APPPOOL\ASP.NET v4.0] from windows;
exec sp_addsrvrolemember N'IIS APPPOOL\ASP.NET v4.0', sysadmin
After that, running our Web Application brings the happy picture again:
What are the drawbacks of this approach? Obviously we lose the benefits of using LocalDB. Installing SQL Server Express may take more time than LocalDB, and there may be some machine cleanup necessary for it to succeed. SQL Server Express Setup can be blocked by problems like corrupt WMI database, polluted registry or components left by SQL Server or Visual Studio CTPs and Betas. And SQL Server Express will continue running in the background even when not needed, as services do.
Other options
There are other approaches of using LocalDB under full IIS that are not covered here. We could embrace the Web Application's private LocalDB instance and communicate with it through the Web Application by executing T-SQL scripts from ASP.NET code. We could also use AttachDbFileName option of ADO.NET connection strings and use a database file (.mdf) that would be attached to both our LocalDB during development and Web Application's LocalDB for debugging. I tried both I found them too cumbersome to discuss further.
Based on the answer from #KrzysztofKozielczyk.
I originally posted an answer here:
https://stackoverflow.com/a/62810876/3850405
After following this I verified that Load User Profile was set to true for my Application Pool and then set setProfileEnvironment to true in applicationHost.config. I did the last part by editing applicationHost.config located at:
C:\Windows\System32\inetsrv\config\applicationHost.config