I have an Azure Web Role running in the new 1.3 SDK and I am having permissions issues when trying to make changes to IIS using the Microsoft.Web.Administration.ServerManager. Whenever I execute CommitChanges() it throws this error:
an UnauthorizedAccessException "Cannot write configuration file due to insufficient permissions".
My ServerManager code is executing in the OnStart method of the RoleEntryPoint.
My understanding was that the purpose of moving to full IIS support in 1.3 was so that we could have greater control over the configuration of our application, including creating new IIS sites on the fly if desired.
Make sure your role is running with elevated privileges.
I think there are two questions here. Firstly the use of IIS in Azure. Yes using the 1.3 SDK means that we now have access to more features than we did previously. This means that we can setup more than one site and virtual directories for our sites in the configs as shown in the training kit.
Secondly there is the privileges issue that you're getting while trying to make changes programatically. I'm going to presume that you're not trying to do one of the things that you can simply do through the config above. The most likely reason your code is erroring is because web roles are not run with admin privileges. Fortunately in the 1.3 SDK we also have a way to run code with elevated privileges. As shown elsewhere in the training kit you can create a separate .exe that you specify to be run at startup with elevated privileges in the config.
Providing a clear example for reference to #smarx answer.
Here is the configuration to run RoleEntryPoint.OnStart (WebRole.Onstart) with Admin-level privileges.
<ServiceDefinition name="MyProject.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2015-04.2.6">
<WebRole name="MyProject.WebRole" vmsize="Small">
<Runtime executionContext="elevated"/> <!-- Required for certain WebRoleOnStart tasks (avoid insufficient permission errors) -->
<Sites>
<!-- ... -->
</Sites>
</WebRole>
</ServiceDefinition>
Related
I've been encountering this problem whenever I try adding a role to my Azure Cloud Project.
The thing is that whenever I update to an older revision of my code, it works fine. It isnt until I try adding a new role or even removing a role and readding it is when I get an error. Even on new projects I cannot get a role added.
Number of things to check/try:
Set the application pool to ASP.NET 4.0. Make sure the application is set to v4.0 as well. Then restart IIS.
Add the following key to <system.webServer> section of Web.Config:
<modules runAllManagedModulesForAllRequests="true" />
Check that the file %userprofile%\documents\IISexpress\config\applicationHost.config exists and the application has the necessary permissions to access it. (IIS Express)
Check the app pool "run as user" and ensure it has rights to the web site directory.
Try running VS in administrator mode and see if debug works. (right click the shortcut and select "run as administrator".
Failing the above post the contents of the file from step 3.
I am trying to use Enterprise Web Library with Windows Azure. It appears that the web.config file for the EWL project works fine locally, but when I deploy to Azure the application cannot initialize. After logging in and viewing the site locally on Azure, it appears there are several web.config elements EWL requires that are locked on Azure. I've had to edit the following in order to have the application initialize on Azure:
Remove <serverRuntime uploadReadAheadSize="8388608" />.
Remove everything nested inside of the modules element.
The application seems to run fine on Azure after removing these parts.
The Web.config elements you removed are important to ensure that EWL works properly: uploadReadAheadSize fixes a problem with client certificate authentication, and using <clear/> in the <modules> section makes the behavior of EWL applications consistent across different servers by keeping the same set of modules in the pipeline regardless of what IIS features are installed on the machine.
There has to be a way to unlock these config sections in an Azure web role. Assuming they are locked in the web role's applicationHost.config file, maybe you can modify this file using a startup script as described in this answer: https://stackoverflow.com/a/10140024/35349.
I am not very familiar with Enterprise Library. If William’s suggestions do not help, please check your web.config to see if you’re missing any configuration sections. On your local machine, when you install Enterprise Library, it may modify machine.config to add certain configurations. But they may not exist in the cloud. So please search your local machine.config to see if there’re any Enterprise Library specific sections, and then add them to your web.config.
Best Regards,
Ming Xu.
I have ASP webrole that works great without ACS. When i add ACS to the my application it works fine locally. However when i deploy it to the cloud its doesnt seem to be packaging the Microsoft.IdentityModel.dll.
Now I have done the following:
Ensured under the References that copy local = true for "Microsoft.IdentityModel"
Tired re-adding the STS references.
3.Right click>>Add referance>>Microsoft.IdentityModel.dll
This used to also work fine without having to install WIF on the actual server.
Any ideas?
Please check out these resources, which might help you solving your issue:
Similar SO Question
MSDN Documentation: Unable to Find Assembly 'Microsoft.IdentityModel' When RoleEnvironmentAPIs are Called
ACS Walkthrough from Windows Azure Team (new)
Powershell script on GitHub for Installing WIF via Stratup Task
Hope this helps!
I manage to find what was causing the issue. So I had 1 x WebRole and also 1 X WCF role in the same solution. ACS worked fine up until three steps later in the application once I tried to use the WCF service. At point it stuck me that the Azure creates a VM per role. So this made total since why it authenticated fine up to the point when I tried to use the WCF service. The assembly was not missing from the WebRole but rather from the WCF VM that it created. So I made sure that WIF was also installed on that VM and bang it worked. I still don’t understand 100% why I would have to have to install WIF on the WCF VM but in the end that what was causing my issue.
The only thing that worked for me is described in this post under "using windows update packages section" (but I had to make some minor changes to the startup script)
Basically, I had to create a Startup Task, which executes batch file InstallWif.cmd that I've created under my web project. I also downloaded and included WIF install package (Windows6.0-KB974405-x64.msu) into my web project. I set "Copy to Output Directory" property to "Copy Always" for both of these files.
InstallWif.cmd contained the following script
#echo off
sc config wuauserv start= demand
wusa.exe "%~dp0Windows6.0-KB974405-x64.msu" /quiet /norestart
sc config wuauserv start= disabled
exit /b 0
Note that I had to use Windows6.0-KB974405-x64.msu and not Windows6.1-KB974405-x64.msu. I found out that 6.1 version wouldn't install by logging to Azure VM instance using a remote desktop connection to Azure and trying to manually install this version there.
Startup task is defined inside ServiceDefinition.csdef file like this
<Startup>
<Task commandLine="InstallWif.cmd" executionContext="elevated" taskType="simple" />
</Startup>
It's been several hours lost now, i just don't get it.
Situation :
- Migrating an ASP.net app to Azure
- IMPORTANT : This is a webrole with several websites, all websites are compiled in a folder "azure.builds" so my sites bindings are like
physicalDirectory="..\azure.builds\www.mywebsite.com"
physicalDirectory="..\azure.builds\cb.mywebsite.com"
and so on
I have a cmd script that works great on my dev machine, which set permission on IIS to execute on an exe file (it has to be called by an html form).
Here is my local code startup.cmd which works against my local IIS :
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers /+"[name='MY_GCI', path='.exe',verb='',modules='CgiModule', scriptProcessor='c:\websites\myproject\azure.builds\cb.mywebsite.com\cgi-bin\mymodule.exe',resourceType='Either']"
On my html form the file is called via action "http://cb.mywebsite.com/cgi-bin/mymodule.exe" and guess what it works.
But in my migration to Azure it doesn't, i'm unable to set permission to this particular file. The problem is i can't figure the full complete path to the EXE files as the example above show.
I tried this (%ROLEROOT%) :
%windir%\system32\inetsrv\appcmd set config /section:system.webServer/handlers /+"[name='MY_GCI', path='.exe',verb='',modules='CgiModule', scriptProcessor='%ROLEROOT%\azure.build\cb.mywebsite.com\cgi-bin\mymodule.exe',resourceType='Either']"
Does not work.
I studied several example involving similar CGI setup (such running PHP) but the difficulty is that the EXE module have to be exposed on http://cb.mywebsite.com/cgi-bin/mymodule.exe wich is not even the main root webiste on my azure webrole, so this is not exactly the same.
Sorry if it is not very clear to understand, let say in short : how to find the full local path of a particular file in a particular site node in a webrole within a startup cmd file ?
It appears you have this value outside of Azure:
scriptProcessor='c:\websites\myproject\azure.builds\cb.mywebsite.com\cgi-bin\mymodule.exe
Now you want the equivalent within Azure. The key for doing this is to use the ROLEROOT environment variable.
It appears you have considered ROLEROOT already, but perhaps there is a little bit off in mapping into your directory structure. I suggest you RDP into the Azure instance and get oriented (look at e:\approot for starters, but you are not guaranteed to always be there, thus the need for using ROLEROOT). RDP: http://msdn.microsoft.com/en-us/library/windowsazure/gg443832.aspx
If your real problem has to do with "...the difficulty is that the EXE module have to be exposed on http://cb.mywebsite.com/cgi-bin/mymodule.exe wich is not even the main root webiste on my azure webrole, so this is not exactly the same." then I am not sure I can help as I am unsure of issue you are describing. But one idea: RDP in (as mentioned above) and try to execute the CGI script by hand in Azure and see how that goes. If that doesn't work, you may have a path or permission problem. If it does work, you still may have a problem related to permissions (since the RDP account will have more power than your default IIS user).
A couple of other things to try: Ensure your Azure Web Role is running with elevated permissions by using the following setting in ServiceDefinition.csdef:
<WebRole name="WebHost">
<Runtime executionContext="elevated"/>
...
And also consider running your startup task elevated, also via ServiceDefinition.csdef:
<Startup>
<Task commandLine="startup.cmd" executionContext="elevated" />
</Startup>
And, finally, some StartUp Task debugging tips:
http://blog.smarx.com/posts/windows-azure-startup-tasks-tips-tricks-and-gotchas
I have WIX installers for two windows services. Both are installed using the same credentials, but one works while the other fails with the error "Service "PCP Event Processor-3.9.9.0-wix' (MyServiceExeName) could not be installed. Verify that you have sufficient privileges to install system services.". I use a common wxi file for both projects with the credentials to use, so it's not an account name or domain name typo AFAICS. The only substantial differences between the two services being installed are:
The failing project has a .licx file for the 3rd party component.
the failing project is a WinExe project. The successful install is an Exe (Console style app)
As far as I can see, there is no real difference (obviously GUIDs are different) between the wxs files for the two installers. The failing component has WIX installer code like this:
<Component Id="cmpMainExe" Guid="{EXCISED-FOR-CUT-N-PASTERS}">
<File Id="filASJHDJSDJSHGDJH" Source="$(var.EventPollingService.TargetDir)\EventPollingService.exe" />
<ServiceInstall Name="$(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
DisplayName="PCP $(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
Type="ownProcess"
Interactive="no"
Start="auto"
Vital="yes"
ErrorControl="normal"
Description="Manages the state model of a user's session by handling incoming events from the dialler"
Account="$(var.ServiceAccountId)"
Password="$(var.ServiceAccountPwd)" />
<ServiceControl Id="StartWixServiceInstaller"
Name="$(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
Start="install"
Wait="yes" />
<ServiceControl Id="StopWixServiceInstaller"
Name="$(var.SVCNAME)-$(var.ProductVersion)-$(var.BranchName)"
Stop="both" Wait="yes"
Remove="uninstall" />
</Component>
I'm using Wix 3.5 with Votive in VS 2010, and both projects are .NET 3.5 SP1 apps. I'm using Windows 7, with UAC turned off.
Any ideas?
Look at the two build MSI's in ORCA from Windows SDK and verify the ServiceInstall table entries look the same.
However, in my experience, this is not likely to be an installer issue. This is usually a red herring that points to an application problem such as missing dependencies or application exception. After you rule out the ServiceInstall entries and verify that the service account credentials are correct, the account is not disabled and the account has the authority to logon as a service then start profiling your application. This is easiest to do right when the installer is hung at the error window.
Two last thoughts:
If a program has dependencies on the winsxs or GAC it won't work as these don't get installed until Commit execution which is after trying to start the service
If you need to grant the user LogonAsService rights look at the User element in WiX.