I have an ASP.NET MVC 3 application which uses PowerShell to connect to Office 365 to retrieve some details about user licenses.
The code itself works in many cases:
The project in my local IIS works
A piece of code in LINQPad using the library works on my machine
A piece of code in LINQPad using the library works on the target server
And where it doesn't work is of course the only place it really should work: The IIS on the target server.
I always get an Exception when calling the Connect-MsolService cmdlet. The problem is that the Exception doesn't tell me anything.
The Exception type is
Microsoft.Online.Administration.Automation.MicrosoftOnlineException
and the message is
Exception of type 'Microsoft.Online.Administration.Automation.MicrosoftOnlineException' was thrown
which is pretty useless.
The Office 365 user account I use in my code is always the same. The user account used to start the IIS is always the same, too (Local System).
I wrapped the PowerShell code execution in a class named PowerShellInvoker. Its code can be found here.
And here is the code that connects to Office 365:
var cred = new PSCredential(upn, password);
_psi = new PowerShellInvoker("MSOnline");
_psi.ExecuteCommand("Connect-MsolService", new { Credential = cred });
There is no Exception actually thrown, the error is found in the Error property of the pipeline. (See lines 50ff. of the PowerShellInvoker class.)
The problem is that I don't know what could be wrong, especially because the same code works when I use LINQPad. The search results by Google couldn't help me either.
The server runs on Windows Server 2008 R2 Datacenter SP1 with IIS 7.5.
I found the solution!
I don't know the reason, but on the target server, the app pool's advanced settings for my app had set Load User Profile to False. I changed it back to True (which should be default) and voilà, it works!
Edit: The Load User Profile setting was apparently automatically set to False by default because the IIS 6.0 Manager was installed and False was the default behavior until IIS 6.0.
Related
I try to get certificates hash from web-site bindings(IIS) using official Microsoft Library Microsoft Web Administration.I stack with one interesting problem.When I try to complete this trivial operation:
foreach (Binding binding in site.Bindings)
{
binding.CertificateHash;
binding.CertificateStoreName;
}
I get this exception: Method or operation is not implemented
The most strange and curious thing that when I create another test project and did same things everything work's fine.This situation blows my mind!I compared the versions of the library.They are equal.(Version 7.0.0)
Of course, I try many other solutions and answers:
1)Got an error while using WorkerProcess.GetRequests method from Microsoft.Web.Administration.dll IIS 8.5
2)State property of Site throwing "NotImplementedException" in IIS Express
3)The method or operation is not implemented. while stopping IIS website in C#
but nothing had happened.So that way I here.
Thanks for your attention!
I have a piece of code in a Web API app:
private Stream ConvertWorkBookToStream(WorkBook workBook)
{
var tempFileName = Path.GetTempFileName();
// The following line throws a NullReferenceException
workBook.write(tempFileName);
// Remainder elided for brevity
}
Neither workBook nor tempFileName are null.
On a whim, I changed the app pool to run under a domain administrator account, to eliminate any permissions issues (since I've observed some general wonkiness on my machine of late) and re-ran it. The same exception was thrown.
Then I created a console application and copied the method, verbatim, into the app and ran it. No exception was thrown.
Now, it bears noting that just yesterday, I ran into a similar puzzling behavior regarding File.Exists.
Consider the following call:
var exists = File.Exists(#"\\myshare\\myexistingfile.ext");
Assuming that the path refers to a file that actually exists:
Under a web app, exists returns false on my machine.
The same operation, in a console application, returns true.
My coworkers are experiencing the opposite behaviors.
Can anyone explain this? I'm rather at my wits' end.
Check to see if the return from Path.GetTempFileName is different from the console app and the web app. Windows could be playing tricks with you. I had similar issues attempting to write log files. I just gave up and put them int the same directory as my web service.
In your IIS Authentication settings, are you only having Anonymous Authentication enabled? If I remember correctly Anonymous Authentication impersonates the IUSR account with restricted privileges.
We have a winforms clickonce application in C# which is granted full trust and signed using a valid certificate.
The application runs fine and updates correctly on Windows XP, Windows 7. However, on a Windows 8 machine, it just fails to update. The application runs correctly though. However, the first update request to move up to a later version fails with: System.Deployment.Application.TrustNotGrantedException
The code failed after the call to ApplicationDeployment::CheckForDetailedUpdate() failed. Wondering why this could happen as the exact same code is running fine on all previous versions of Windows. Any help will be appreciated. Below is the relevant stack trace:
System.Deployment.Application.TrustNotGrantedException: User has refused to grant required permissions to the application.
at System.Deployment.Application.ApplicationTrust.RequestTrust(SubscriptionState subState, Boolean isShellVisible, Boolean isUpdate, ActivationContext actCtx, TrustManagerContext tmc)
at System.Deployment.Application.DeploymentManager.DetermineTrustCore(Boolean blocking, TrustParams tp)
at System.Deployment.Application.DeploymentManager.DetermineTrust(TrustParams trustParams)
at System.Deployment.Application.ApplicationDeployment.CheckForDetailedUpdate(Boolean persistUpdateCheckResult)
at System.Deployment.Application.ApplicationDeployment.CheckForDetailedUpdate()
The only time I'd seen this stack trace was when I tried calling CheckForDetailedUpdate() without setting up the explicit trust before hand. After adding the code below, the update check worked.
// Setup the trust level
var deployment = ApplicationDeployment.CurrentDeployment;
var appId = new ApplicationIdentity(deployment.UpdatedApplicationFullName);
var unrestrictedPerms = new PermissionSet(PermissionState.Unrestricted);
var appTrust = new ApplicationTrust(appId) {
DefaultGrantSet = new PolicyStatement(unrestrictedPerms),
IsApplicationTrustedToRun = true,
Persist = true
};
ApplicationSecurityManager.UserApplicationTrusts.Add(appTrust);
// Check for update
var info = deployment.CheckForDetailedUpdate();
From this MSDN page there are two causes. But it seems TrustNotGrantedException is usually raised when a new ClickOnce update has been deployed that uses more privileges than the previous version...
The application uses permission elevation and the user denies the request for elevated trust; or
The application uses Trusted Application Deployment and the digital certificate used to sign the application is not listed as a trusted publisher on the local machine. If you have deployed an update to an application, and the update uses more permissions than the previous version, and ClickOnce throws a TrustNotGrantedException, the new version will not install.
So it makes sense that it would fail to update, because the apps security level has changed since the user last installed it - so they will need to reinstall it.
We had the same problem and ended up using the InPlaceHostingManager class. It's made for installing or updating a ClickOnce deployment. GetManifestAsync() fires the GetManifestCompleted event, which gives you the version number. Then you can call DownloadApplicationAsync() and handle the DownloadApplicationCompleted event. So far this works and no TrustNotGrantedException is thrown.
I have some utility methods that use Microsoft.Web.Administration.ServerManager that I've been having some issues with. Use the following dead simple code for illustration purposes.
using(var mgr = new ServerManager())
{
foreach(var site in mgr.Sites)
{
Console.WriteLine(site.Name);
}
}
If I put that code directly in a console application and run it, it will get and list the IIS express websites. If I run that app from an elevated command prompt, it will list the IIS7 websites. A little inconvenient, but so far so good.
If instead I put that code in a class library that is referenced and called by the console app, it will ALWAYS list the IIS Express sites, even if the console app is elevated.
Google has led me to try the following, with no luck.
//This returns IIS express
var mgr = new ServerManager();
//This returns IIS express
var mgr = ServerManager.OpenRemote(Environment.MachineName);
//This throws an exception
var mgr = new ServerManager(#"%windir%\system32\inetsrv\config\applicationhost.config");
Evidently I've misunderstood something in the way an "elevated" process runs. Shouldn't everything executing in an elevated process, even code from another dll, be run with elevated rights? Evidently not?
Thanks for the help!
Make sure you are adding the reference to the correct Microsoft.Web.Administration, should be v7.0.0.0 that is located under c:\windows\system32\inetsrv\
It looks like you are adding a reference to IIS Express's Microsoft.Web.Administraiton which will give you that behavior
Your question helped me find the answer for PowerShell, so if the Internet is searching for how to do that:
$assembly = [System.Reflection.Assembly]::LoadFrom("$env:systemroot\system32\inetsrv\Microsoft.Web.Administration.dll")
# load IIS express
$iis = new-object Microsoft.Web.Administration.ServerManager
$iis.Sites
# load IIS proper
$iis = new-object Microsoft.Web.Administration.ServerManager "$env:systemroot\system32\inetsrv\config\applicationhost.config"
$iis.Sites
CAUTION! Using this approach we have seen seemingly random issues such as "unsupported operation" exceptions, failure to add/remove HTTPS bindings, failure to start/stop application pools when running in IIS Express, and other problems. It is unknown whether this is due to IIS being generally buggy or due to the unorthodox approach described here. In general, my impression is that all tools for automating IIS (appcmd, Microsoft.Web.Administration, PowerShell, ...) are wonky and unstable, especially across different OS versions. Good testing is (as always) advisable!
EDIT: Please also see the comments on this answer as to why this approach may be unstable.
The regular Microsoft.Web.Administration package installed from NuGet works fine. No need to copy any system DLLs.
The obvious solution from the official documentation also works fine:
ServerManager iisManager = new ServerManager(Environment.SystemDirectory + #"inetsrv\config\applicationHost.config");
This works even if you execute the above from within the application pool of IIS Express. You will still see the configuration of the "real" IIS. You will even be able to add new sites, as long as your application runs as a user with permission to do so.
Note, however that the constructor above is documented as "Microsoft internal use only":
https://msdn.microsoft.com/en-us/library/ms617371(v=vs.90).aspx
var iisManager = new ServerManager(Environment.SystemDirectory + "\\inetsrv\\config\\applicationhost.config");
This works perfectly. No need to change any references
I am working on integrating my company's product with Jira so users can log bug reports directly from the application. Everything was wqorking smoothly so i decided to import the data from our live Jira system into my development system so that i had some real world data to play with. Since then when i try to get an authtication token it throws the following exception "com.atlassian.crowd.exception.PasswordEncoderNotFoundException: The PasswordEncoder 'atlassian-security' was not found in the Internal Encoders list by the PasswordEncoderFactory". I have checked and the Atlassian Security Password Encoder is enabled in the Crown Password Encoders plugin.
My code is super simple just an ASP.net based text based issues search with the results wired to a grid view code as below:
JiraSoapServiceService service = new JiraSoapServiceService();
string token = service.login("integration", "test");
if (!string.IsNullOrEmpty(txtSearch.Text))
{
RemoteIssue[] issues = service.getIssuesFromTextSearchWithLimit(token, txtSearch.Text, 0, 100);
gvwIssues.DataSource = issues;
gvwIssues.DataBind();
}
I get the error on the call to service.login, it worked fine before I imported the live data. And yes i did add the integration user again after i had imported the data.
Anyone any ideas on this.
No idea what was causing this but rebooting the PC that the dev Jira was installed on fixed it.
EDIT
I have had this a few times now. It tends to happen when you do something like restart the SQL server, restore the jira database via SQL server, restore jira via the inbuilt XML file import method or similar. You don't have to restart the machine just the jira windows service. No idea if this is a problem with other DBs or server types.