Setting: Exchange Web Services (EWS), Exchange Server 2007 SP2, and an ASP.Net web application.
Problem: in the system we use EWS to send emails, sometimes we use extended properties to track more information. This module had been working fine for a long time until a couple of weeks ago, and I am not sure why or what is causing the Active Directory is unavailable error!!
The thing is that there is no pattern (or I am not able to find one so far), sometimes it works fine and sometimes I get the AD error.
I've been searching for more info about this error and didnt find much!
After long investigation and the help of our IT support team, the problem was with one of the Active Directory servers (not sure what was wrong with it) but all requests that went to this server gave this error, they took it down or restarted it and everything worked again
Related
My team is in the process of developing an Office 365 add-in, specifically to enable interaction with a hosted web application, and we're encountering a "Permission needed / Bad Request" error that we can't seem to pin down.
Context:
Developing and testing the add-in involves configuring an Azure Active Directory v2 application via the management portal as well as (for development purposes) creating an xml manifest file (which is for v1 apps as opposed to the json format for v2) that can be side-loaded via the O365 interface to provide access to our hosted app (currently only xml manifests can be side-loaded). We're still very much in the process of figuring things out in Office 365, as well as Azure/Active Directory and Microsoft Graph, and the documentation is fairly broad and doesn't always seem to be up to date.
Problem Description:
One of the problems that we're run into occasionally is encountering a "Bad Request" dialog message (in a browser dialog titled 'Permission needed') that is displayed when clicking the toolbar icon for our add-in. The actual URL being requested is similar to https://store.office.com/client/consentnotification.aspx with a number of parameters representing our application and it's required permissions. This results in an HTTP 400 with "Bad Request" being the only response content.
This is happening when the user clicks on our add-in in the O365 application toolbar and is occurring at the point where the user would have to authorize permission for the add-in.
This error seems to be related to the application configuration, but we can't seem to sort out how specifically (ie, some developers are encountering it, and others are not. Sometimes it'll show up if we recreate the Azure Active Directory application using one version of portal or another (there are currently two, with the v2 version being in preview).
Can anyone offer suggestions as to what might be causing this or provide information on why this might be occurring? We're not blocked, but it is rather annoying to deal with in development. I've done a fair bit of research trying to sort out why this is happening and I've gone through a number of tutorials/introductions on configuring Azure apps without success.
This turned out to be related to the Azure Active Directory Application configuration.
For the applications where this was occuring, the AADv2 application manifest was using a "signInAudience" value of "AzureADMyOrg". For cases where it was working as expected (ie, properly populating the permission request dialog) the "signInAudience" was set to "AzureADandPersonalMicrosoftAccount".
After some testing, the solution for our particular problem seemed to be either manually editting the AADv2 application manifest (json) to have "signInAudience": "AzureADandPersonalMicrosoftAccount", or via the Portal by setting the Application's Authentication Supported Account Types setting to be "Accounts in any organizational directory" (this results in a manifest setting of "signInAudience": "AzureADMultipleOrgs" which also seems to work).
I have been making requests to my cloud REST Service over the two past weeks. Everything was fine until yesterday.
Over the past days, I kept re-publishing my service to the cloud to test some of its operations with a client. I DID NOT change anything in my web.config, just some method bodies.
Yesterday, by making the simplest GET request to my service, through my browser or Advanced Rest Client, i started getting the following error:
The server encountered an error processing the request. Please see the service help page for constructing valid requests to the service. The exception message is 'The underlying provider failed on Open.'. and so on
I suspect after doing my research that this means I clearly have a connection error with my database which I don't get since it was working fine so far.
I also tried to Stop and Start my service in the Azure Production Enviroment but without any luck. Also the server firewall is configured as it should be.
Any answers would be much appreciated.
Thanks.
In my experience these generally tend to be azure service outages. There is currently 'Scheduled maintenance' occurring on all DB instances which may be affecting you.
http://www.windowsazure.com/en-us/support/service-dashboard/
We currently have a Silverlight application which is hosted in a SharePoint 2010 page. The Silverlight app makes web service calls to a another server on our domain, which has a clientaccesspolicy file in place. We are experiencing cross-domain issues in our production environment.
Users in the farm admin group can use the Silverlight application without any issues. However, all other users recieve the generic cross domain exception when they try to use this app. We have attached Fiddler to the process and noticed that the farm admins are served the clientaccesspolicy file, but that non-admin users are not. In fact, Fiddler does not ever show an attempt to load this file for non-admins.
This only happens in our production environment, which leads me to believe there is a web config or permission setting causing the issue. Unfortunately, I cannot find anything that backs this up.
Has anyone else run into this issue or know if such a setting exists?
See comments above. I had to change the URL to use the full machine name i.e. from webserver/service.svc to webserver.domain.com/service.svc. It solved the problem but doesn't answer the question about why the farm admins could access it. vorrtex's response is the best possible explanation I have seen so far.
I created a WPF Desktop application and have tried deploying it to vista without success. The application performs a scan and uploads the data to a web service on the internet. It should also log any exceptions using NLog to the hard drive. When I run the application it errors out when trying to send the data to the web service. If I run it as administrator it works fine. I have tried a number of things but nothing seems to work. Nlog doesn't log the exception so it's difficult to tell what is happening. Any direction would be greatly appreciated.
Adding a strong name to my application allowed it to be given full trust on the machine. This solved any issues getting to the external web service. Go here to learn how to sign your application.
This morning, something wierd happened with our Active Directory.
We have a website that authenticates users against our Active Directory. It has worked flawlessly for weeks. The code involving this has never changed. When I launch a copy of the website on my local computer within the IDE (VS2008), it authenticates users correctly, and determines what groups they belong to correctly. When I navigate to the actual website though, it authenticates but fails to retrieve any group information. While I am open to the possibility that it would be code, I am very skeptical of this since the code has not changed since the last time it was working, which was yesterday.
I wrote a quick app using the same exact programming code, but in a compiled WinForm instead of a webpage. The App can authenticate and retrieve all the groups flawlessly. So it is just the website that, all of the sudden, cannot access the groups. I am sure this is relevant, but I am not sure how =)
Being a programmer and not a Server Admin, I am unsure where to begin in hunting down this problem and will appreciate any assistance the community at large can provide.
If you have anonymous browsing turned off, check to see that the account the web app is running under has the correct permission.