I'm testing the AppFabric cache feature in my website deployed from ASP.net MVC 4. In the web.config of my website, if I set the security level to anything except no security (None/None), like this
<securityProperties mode="Transport" protectionLevel="EncryptAndSign" />
then, getting cache from the method below will throw exception,
DataCacheFactory.GetDefaultCache()
Also, in the PowerShell Cache Management, I've already set the protection level to the same level (Transport/EncryptAndSign).
But getting cache still failed.
Exception message is as following,
ErrorCode(ERRCA0017):SubStatus(ES0006):There is a temporary failure. Please retry later. (One or more specified cache servers are unavailable... )
The situation only happens in my deployed website. But if I run my website in Visual Studio debug mode, cache would response successfully no matter what the security level is set to.
OK! I finally solved the tricky issue. This tough thing nearly made me contribute my 50 bounties (almost half) !
After some survey, I found the first clue,
Security Error in APPFabric when changed the security mode from None to Transport?
(Note, I can't easily google it out from some keywords, but the result I want was easily dug out from Msdn AppFabric Cache forum. I thought google search can help me to find any answer.)
I got the same exception message as the first link. But Rahul's answer didn't work. However, Rahul's link revealed a second clue, that is, use Tracelog.exe to track the connection problem.
From the track log in Event Viewer, I found there are some error events saying my server's authority isn't accessible, so I searched in the third clue, Cache Administration PowerShell commands for setting permission in PowerShell.
In the third clue, thank the author, mark_og who really saved me ! You taught us how to set the permission in IIS like this,
Grant-CacheAllowedClientAccount "IIS APPPOOL\[AppPoolName]"
it's the key answer which solves my problem !
Related
I am facing a weird problem today, when running my MuleSoft application locally from my AnypointStudio and firing a request from postman, I am getting 403 error. When debugging I found out that the application is checking for flowVars._clientName, however it is missing. According to this documentation, actually yes flowVars._clientName is expected.
https://help.mulesoft.com/s/article/How-to-get-the-client-application-name-in-a-flow-based-on-the-client-id-and-client-secret.
So my application fails with 403 error. Seems that other environments are working perfectly fine.
And yes it is using Client Id enforcement.
Any clues?
Without more details it looks like the issue is inside the logic of your application. The KB article that you referenced is a how to in case you need to obtain the client name. It doesn't say that you have to use for authentication. You don't describe how the application does authentication/authorization. Is it in a flow? Or in a policy? If it is the standard Client ID enforcement policy, the expressions to evaluate client id and secret can be configured, but I don't think the default is not #[flowVars._clientName] nor #[flowVars._clientId].
Note that Exchange is basically a repository of APIs and other artifacts. It doesn't authenticate anything at execution time. Unless your application is trying to use it somehow, but I can't think of a reason for that.
The issue was resolved only by re-downloading Anypoint Studio and mule runtime. Very weird, it was happening only for one application, not for the others. Creating a new workspace did not help, deleting the application and re-cloning and installing did not help, even recloning in a new directory did not help. Only using a new Anypoint Studio and runtime installation resolved it (even with the old code base) ...
I want to deploy my WCF web Service on Azure plateform.
I have created a Storage account for my website, and also created a cloud Service and uploaded my package file and config file to the staging site.
But while uploading, The message displays
'Your staging deployment is starting. Hang on, the page will refresh once the deployment begins.'
I am waiting sice 2-3 hours and not getting the desired output.
Am I doing correctly? Or is there anything that I forgot?
Please Help...!
Most likely there is a problem in your code or the packaging that is causing the role to continuously restart. This is a fairly common problem, but there are a lot of possible causes (missing an assembly reference, an uncaught exception, the Run() method is exiting, a Startup Task is failing, or many other things). You need to gather more information to know exactly what the problem is and how to fix it.
There are many threads here on SO about this topic. There's also a Microsoft post discussing how to diagnose this type of issue. Those are good places to start.
I'm about a month away developing my silverlight application (this is my first). Everything went rather smoothly until today, when out of the blue I started getting this message:
An error occurred while trying to make a request to URI 'http://localhost:2682/Services/Authentication/LoginService.svc'. This could be due to attempting to access a service in a cross-domain way without a proper cross-domain policy in place, or a policy that is unsuitable for SOAP services. You may need to contact the owner of the service to publish a cross-domain policy file and to ensure it allows SOAP-related HTTP headers to be sent. This error may also be caused by using internal types in the web service proxy without using the InternalsVisibleToAttribute attribute. Please see the inner exception for more details.
I'm using WCF Services and this issue never appeared until now.
I've added a clientdomain.xml and clientaccesspolicy.xml file to my [projectname].web folder, and re-wrote them about a 1000 different ways.
I've also used Fiddler and it shows me that the error is on both those files, the error is
[Fiddler] The socket connection to localhost failed. ErrorCode: 10061. No connection could be made because the target machine actively refused it 127.0.0.1:2682
I've searched the error "10061" and it has to do with socket definition. But I couldn't find any solution to that.
Don't know if it has anything to do with it, but my "ASP.net Development Server" port is 6939.
Keep in mind that the app has NOT been deployed, so this is only happening locally. I'm using MS VS 2010 and MS SQL Server 2008.
Am I doing anything wrong or is this a silverlight issue??
On a last note, I haven't changed anything on Port, socket or service configuration. Last thing I was doing was editing a XAML file on client side and and the app started throwing me this error.
Need help, can't do anything until this is solved!!!!
Thanks.
i think you are using you app on localhost and a dynamic port is getting assigned and this port is not fixed and every run and that causes the refuse problem. if you want to fix this, create a solid url for example,
http://localhost/apps/Services/Authentication/LoginService.svc
Well, last night, just before I went to bed, I noticed something odd. In my "ServiceReferences.ClientConfig" file, the endpoint ports for each one of my services where diferent from the ones the silverlight machine used, so going on a hunch (and because I was reaching my sanity breakpoint) I decided to eliminate all my Service References and re-add them again.
I worked... go figure. Still don't know why this happened and if anyone could shed some light on the subject, I would appreciate it. It's kinda of annoying having to re-add all my services references. Right now I have only 6 of them, but in the near future they may go over 20, and if this happens again... well, it's going to be a real pain...
Thanks
When running a web deploy to a specific IIS site I get the following error:
Error: The synchronization is being stopped because the maximum number of sync passes '5' has been exceeded even though all the changes could not be applied. This could occur if there are external changes being made to the destination.
At C:\Code\.....\deploy.ps1:185 char:10
+ & <<<< ($appDeployCmd) $type /M:$url /U:$user /P:$pass /A:Basic -allowUntrusted -useCheckSum
+ CategoryInfo : NotSpecified: (Error: The sync...he destination.:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
Web Deploy is working fine on this environment against other IIS sites and file syncs are also working. I have previously been able to use web deploy to deploy this specific site without issue. All of the sudden out of nowhere, this issue started happening and I can no longer deploy this site.
I'm doing a basic site deploy with a package built from msbuild. I don't think the specifics are that important because as I said this was all working before and currently works against other sites on the same server farm without issues.
The error message says:
"This could occur if there are external changes being made to the destination."
but I'm not sure how to track this down or if it is even the issue to begin with. I've made sure all explorer windows are closed in all remote sessions. I've tried restarting the site and the app pool. The only thing I have not tried is rebooting the server which is not possible at moment.
Any ideas what might be cause this web deploy to fail?
I had the same error and the problem was my dropbox.
I was working directly in my dropbox folder, and when you publish, it causes dropbox to syncronize at the same time, which caused the error.
Disabling dropbox sync while working solved the problem.
I recon the problem also could happen with onedrive, google drive and so on.
We had this problem when converting from a previously adhoc deploy of a service to MSDeploy, and found that if there were files that were either
marked as read-only via the DOS/Windows read-only file attribute.
inaccessible due to ACLs
then we would get the "maximum number of sync passes" error on deploying.
Once we fixed the attributes/ACLs, we were able to sync.
Quick and easy way to resolve this issue is to delete the files in the destination and re-run the web deploy.
The issue seems to revolve around the ACL step of the web deploy, which attempts to change the permissions of your websites files as a safety measure intended to ensure they are not changed during a deployment.
By default Web Deploy sets the ACL of the sites anonymous user to read only while also overwriting Control Panel access to your website.
Source
You can turn of ACL in future to avoid this if you wish, but it's not really worth it. This will also speed up web deploys - but that is a separate issue.
Not really an answer, but one workaround you can try if you are using the Web Deploy dirPath, filePath, or contentPath providers is the ignoreErrors provider setting. If you know that you are consistently hitting a certain error number, you can specify that that error be ignored when it's hit. See the dirPath provider article for full details (and caveats).
In my case I couldn't fix it but realised the deployment worked regardless.
If you are reading this I wouldn't suggest to just assume it worked, and if it did that it deployed fully, but consider that it may be a false alarm!
I have some WCF services which are running great locally; client can consume them and the server is putting data in the DB as expected. The problem is that when I deploy these to a staging machine, all I can see are HTTP 500 errors.
How do I start debugging the problem?
Given that it's only on staging and not on my local dev machine, I assume it's an IIS configuration problem somewhere.
When I use Fiddler to see what's being sent and what the response is, I can see (as expected) correct request data, and only a 500 as the response -- no further details.
I'm pretty green to WCF and IIS, so it's probably something obvious; I've used aspnet_iisreg, deployed my .svc file and all the built DLLs/files from bin; maybe I missed something.
I looked in the IIS logs, but they're pretty skimpy; no error information there, either (or maybe I'm looking in the wrong place?)
(More important than solving the specific problem is figuring out how to see enough details about errors so I can work through problems myself.)
Edit: I of course checked the event logs first -- and surprisingly, didn't find any mention of the exceptions. So I assume that the service is at least being invoked, and that something is faulting in the middle.
The first place to look for errors is event log on the server. There should be basic information why request was not processed. If it is WCF related you can turn on WCF tracing and check for more details in generated logs.
Add:
<httpErrors errorMode="Detailed"/>
In Web.config under:
<system.webServer>
And see what's happening in more details.
'Http 500 Internal Server Error' might occur if your Service Account's password got expired. Please make sure that you don't have any issues with Service Account which is running the app pool on IIS.
It turns out that the server was returning a 500 because of a huge dataset returned; WCF puts some limitations on the size of data (and strings) you can return, to prevent DOS attacks. I solved the problem by increasing the limits, and decreasing the size of data returned (where applicable).