 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / ASP.NET / Web Services / July 2005WSE464: No policy could be found for this message.
We had a strange thing occur that I cannot duplicate and therefore debug and fix for next time. This is an app and web service that have been working together with WSE2 for many many months. Last night I was told that on one particular function in teh application, they were getting the above message. Over and over again from numerous computers. This morning, when I tested it from MY computer , hitting the same webserver, I did not have the problem. They said the problem also disappeared this morning. I don't know where to start investigating this. This function was the 3rd in a series of WSE2 wired web services calls. So it wasn't that the webserver disappeared. They would always get past the first two and then get this on the third call (the particular function). What type of event would cause this to disappear and then reappear. These computers were all hitting the webserver through the internet and through an ISA Server. They endpoints have not changed. Nobody edited the policy config file. Can anybody get me pointed in the right direction? Thanks!! Julie Lerman This is just a wild guess, but I'd check the event log for messages that the web service process was recycled at the time the problem disappeared. If you find such a message then this would suggest that the problem could have something to do with low resource conditions. Regards, Sami > We had a strange thing occur that I cannot duplicate and therefore debug > and fix for next time. [quoted text clipped - 20 lines] > > Julie Lerman well, I'll take any wild guesses How can I see this in the IIS logs? I see lots of gets and posts of course I also see places where the headers are inserted (column headers like you get at the beginning of the file) If the resources were low, wouldn't it reject every request? Not just certain ones? The first request is a ping which has no requirements (no encryptoin or signing) on it's endpoint. The second request is a login and that is encrypted and signed. The third request is posting some data - sending data to the webservice. That is where it was failing. They stopped and started the app and they tell me it was consistent like this on 3 computers. Julie > This is just a wild guess, but I'd check the event log for messages that > the web service process was recycled at the time the problem disappeared. [quoted text clipped - 28 lines] >> >> Julie Lerman The policy to be applied is resolved using the endpoint and its possible that the ISA server is altering the endpoint ever so slightly (read case). The policy resolution is case sensitive so that could be a cause. The other thing that could be happening is that ISA server is routing to the web service and translating the domain name of your endpoints... i.e. hostname.domain.com/webservice.asmx to hostname/webservice.asmx Try seeing if you can factor your policy cache so that you use default endpoints if none is automatically resolved. Turn policy trace on just to see what the endpoints are that are being resolved to the default policy and that should give you a clue on how to solve the issue from there on. > We had a strange thing occur that I cannot duplicate and therefore debug and > fix for next time. [quoted text clipped - 20 lines] > > Julie Lerman  SignatureHTH Regards, Dilip Krishnan MCAD, MCSD.net dilip.krishnan AT apdiya DOT com interesting and thanks. so here's what I have learned and tried, based on your insight. This problem happened again today all morning and then it magically was okay at about 3pm. Before it resolved itself, I did look at the tracing, but just the soap , I didn't get a chance to trace the policy before the problem disappeared. What I saw is that the outgoing message looked find (from the client) and ws being processed becasue I was getting the correct data back from the web server. However the incoming message had no policies applied to it! So it was the client app that was rejecting the message. I discovered that at this time and the last time we had the problem, the i.t. guys were working on the exchange server and had taken it down. The exchange server happens to be the master domain controller on the network. THe webserver is on a different box and the isa server is on a different box. The problem is only happening when coming in through the isa server. No problems in-house on the intranet. My endpoints are upper and lower case. They are like that in both policiy files (client and server) and also in the actual application. As an experiment, I changed the CLIENT policy file so that the endpoints were all upper case. But I had no problems with my web services this way. (I.E. at this point, everything was working and I couldn't break it by changing this particular policy file) I am not sure if any of these points will help, but can you make anything out of it? I would like to understand it so that I can protect my apps in the future. Julie > The policy to be applied is resolved using the endpoint and its possible > that the ISA server is altering the endpoint ever so slightly (read case). [quoted text clipped - 32 lines] >> >> Julie Lerman Julie, So for operation 3 the response message made it back to the client before you received the WSE464 error, right? As stated before, one possibliity is that the client-side policy enforcement was unable to lookup the policy. I wold double and triple check the endpoint reference and compare with your policy. Do you have operation-level policy specified? If so, what are the variations between the policy for operation 2 and operation 3? Do you have traces from the client-side input filter that show the response messages when it was failing and when it was working? Are they effectively the same? Could it be possible that the client-side policy enforcer was unable to authenticate a server token? What type of security token are you using in the response message? Just some thoughts. Cheers, ~Mork Dan Mork Inetium, Inc. Mork Thanks for the things to consider. I am still here - just had to go away and now have to hammer out three deadlines in the next few days, so will revisit this in about a week. Julie > Julie, > [quoted text clipped - 22 lines] > Dan Mork > Inetium, Inc. Hi Julie, How is it going? I remember meeting you at TechEd2005 :) Are you still experiencing this problem? Let me know and I shall help. I think I still have one of your business cards, so I can ping you directly for any trace files and related files to diagnose the issue better. Let me know. Thanks, Sidd [MSFT] > Mork > Thanks for the things to consider. I am still here - just had to go away [quoted text clipped - 28 lines] > > Dan Mork > > Inetium, Inc. Sidd, Please update this thread if you find anything out. Thanks. Cheers, ~Mork We have really chalked it up to the exchange server being down. It happened both times that they took it down. But it wasn't long enough for me to debug the problem and we weren't willing to take the server down again. Someone emailed me last week having the same problem (though not the same cause). I will find out if it has been resolved and post back here. Julie > Sidd, > > Please update this thread if you find anything out. Thanks. > > Cheers, > ~Mork Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.