I have a problem in the following code where I used an MSMQ queue:
Message m;
if (t! = TimeSpan.Zero)
{
m = q.Receive (t);
}
plus
{
m =
q.Receive ();
}
What I am doing is consuming a web service that uses this code. The problem is that if I test it locally using the Visual Studio debugger it works. But when I send the message using the service that is deployed in the IIS, when the Receive () method is executed it returns a TimeOut error, apparently due to the lack of permissions.
System.Messaging.MessageQueueException (0x80004005): The timeout for the requested operation has expired
Investigating I think it could be because when using debugger the user who accesses the queue is the one who encounters the session started on the computer. And when the consumption from the service URL the user who accesses is the IIS / DefaultAppPool. But I'm not sure, and I can't make it work, if anyone has any idea of how qualitative the solution would be, I appreciate it in advance.
I am working on Windows Server 2016 with .NetFramework 4.8.
Related
I have a HaProxy load balancer on front of some IIS webservers. Haproxy checks the iis apps on a specific path if they are up or in maintenance.
I would like to make a solution, where I can safely reboot a random IIS machine and then have this to trigger my iis application to:
React to the reboot and return a certain response code (a 404 in this case) on a specific path
Stall the host machine reboot for 15 seconds to ensure all calls have been dealt with and that haproxy has seen this 404-status code signalling an upcoming reboot of the iis server.
Is it in any way possible to do these two things?
Windows Server 2016, .Net 4.7.2
This will not work, as all calls to the IIS will return "Service unavailable" when the IIS is running the Application_End code:
protected void Application_End()
{
var log = SystemLogManager.GetLogger(GetType());
try
{
log.Warn("Ending application. Hanging for 15 seconds...");
Thread.Sleep(TimeSpan.FromSeconds(15));
log.Warn("Done end");
}
catch(Exception ex)
{
log.Error("Unexpected error in application end", ex);
}
}
You can write a powershell script that you can call on any server and:
Make a webrequest to the check page that set a cache variable "logoffinprogress"
The check page check the cache variable and respond with a 404 http error code
The powershell script wait for 15 seconds and then reboot the server
On server restart iis is working and the checkpage respond with http 200 code
I hope that this can help you
I'm developing (as a totally no-C#-guy) a web app which communicates with an external data source over OData (server B, some windows 2k12 machine).
The web app runs (is about to run) on an IIS (server A, another windows 2k12 machine), the OData source is a Dynamics NAV 2015 service (the first mentioned windows 2k12 machine, server B).
I'm developing it in VS2013 and if I'm running this locally (meaning: without publishing it, only running it within the local express IIS) it works without any problems at all.
But as soon as I publish it to the target IIS (server A) I'm getting:
An error occurred while processing this request. ---> >System.Data.Services.Client.DataServiceClientException: Unauthorized
at System.Data.Services.Client.QueryResult.ExecuteQuery()
at System.Data.Services.Client.DataServiceRequest.Execute[TElement]>(DataServiceContext context, QueryComponents queryComponents)
--- End of inner exception stack trace ---
This is esentially the piece of code which deals with the OData call:
ODataOrders.NAV odata = new ODataOrders.NAV(new Uri(serviceUri));
System.Net.NetworkCredential nc = new
System.Net.NetworkCredential(_oDataUsername, _oDataUserPassword, _oDataDomain);
odata.Credentials = nc;
DataServiceQuery<ODataOrders.Orders> query =
odata.CreateQuery<ODataOrders.Orders>("Orders");
orderList = query.Execute().ToList(); // "Unauthorized" is being thrown here
It looks like the credentials are being sent/accepted if running from local IIS. And if running from the target (production) server A, the credentials are being somehow lost/overwritten? I really don't know now...
Server A and Server B are in the same domain. My development environment isn't - I can even connect from home through VPN to my work domain and launch my local IIS and still be able to get that request done (the request goes through my local IIS and reaches the Dynamics NAV service so the data is being actually fetched).
Any help would be appreciated...
EDIT
It's Dynamics NAV 2015 CU11.
After some serious hours of reading, programming and trying I've stumbled upon a post here which gave me an idea.
And guess what? It worked - somehow...
Instead of:
System.Net.NetworkCredential(_oDataUsername, _oDataUserPassword, _oDataDomain);
I submitted only:
System.Net.NetworkCredential(_oDataUsername, _oDataUserPassword);
I turns out somehow the domain caused the call not to be authorized (401 error).
I'm currently learning Extending Microsoft Dynamics CRM Online and On Premise Course provided by Microsoft.
I'm simply following the steps according to this lab documentation. The code should be perfectly working but it doesn't work for me.
Connection Strings:
<connectionStrings>
<add name="CRMOnline"
connectionString=
"Url=https://xxxxxx.api.crm5.dynamics.com/XRMServices/2011/Organization.svc;
Username=xxxxxx#damnits.onmicrosoft.com;
Password=xxxxxx;"/>
</connectionStrings>
The connection :
CrmConnection con = new CrmConnection("CRMOnline");
IOrganizationService service = new OrganizationService(con);
WhoAmIRequest req = new WhoAmIRequest();
var result = service.Execute(req) as WhoAmIResponse;
if (result != null)
{
Console.WriteLine(String.Format("Organization ID: {0}\nBusiness Unit ID: {1}\nuser ID:{2}", result.OrganizationId, result.BusinessUnitId, result.UserId));
Console.ReadLine();
}
The exception is caught in this line :
var result = service.Execute(req) as WhoAmIResponse;
Innerexception said "Invalid Request".
I have made sure the credentials on connectionStrings are correct multiple times
I think I have already synchronized the date & time for my pc and the CRM (synchronized internet time & selected the correct time zone on both PC & CRM. Even tested created a record & checked date&time created is correct.)
What else could cause this error?
Thank You.
Hopefully this helps someone else, I was fighting with this same error for a good while today as well.
Turns out I was using an older version of the Microsoft.CrmSdk.CoreAssemblies nuget package(7.1.1 in one project and 8.0.0 in another) as soon as I updated it to the latest (8.2.0.2) I was able to successfully connect to CRM Online.
The error "An unsecured or incorrectly secured fault was received from the other party" usually means that the password is incorrect, but it can also occur if the time between the application and the CRM server is more than 5 minutes apart. I have seen this happen when an application is deployed to a virtual server and the VM experiences "time drift" - it might work at some point, but the VM may slowly get out of sync with internet time and then run into issues authenticating.
From this forum thread
I've got a WinForm application and a service that does some work from the application on a server. I want the user to able to control the service from the application, so I added a ServiceController to do all the work (Start, Stop, Restart at first only). Everything works fine so far but while testing different scenarios I encountered a problem: My service is running on a server, the application is running on a client in the same network. I connect to the service and open the ServiceController.
I then shut down the server (VM) where the service is running and trigger the stop method from the client. I use the WaitForStatus method with a timeout, problem is: the timeout is seemingly ignored by the app:
public void StopService()
{
if (this._serviceController.CanStop &&
(this.ServiceStatus == ServiceControllerStatus.Running || this.ServiceStatus == ServiceControllerStatus.Paused))
{
this._serviceController.Stop();
this._serviceController.WaitForStatus(ServiceControllerStatus.Stopped, TimeSpan.FromSeconds(30));
}
}
In my case, the methods seems to try to stop the service for around 90 seconds and then throws an InvalidOperationException, which I can handle but I don't want the user to wait 90 seconds.
I think my question basically is: What happens when the timer (30 seconds in this case) runs out? Shouldn't the code just continue to run? And when does this function throw an TimeoutException? MSDN says when "The value specified for the timeout parameter expires." - but it seems like this doesn't mean after the value reaches zero.
Can someone enlighten me?
When we specify TimeSpan, WaitForStatus will rise timeout exception after waiting for given time but it seems to be you having exception on privileges.
please read this answer.
All,
I have a WCF web service (let's called service "B") hosted under IIS using a service account (VM, Windows 2003 SP2). The service exposes an endpoint that use WSHttpBinding with the default values except for maxReceivedMessageSize, maxBufferPoolSize, maxBufferSize and some of the time outs that have been increased.
The web service has been load tested using Visual Studio Load Test framework with around 800 concurrent users and successfully passed all tests with no exceptions being thrown. The proxy in the unit test has been created from configuration.
There is a sharepoint application that use the Office Sharepoint Server Search service to call web services "A" and "B". The application will get data from service "A" to create a request that will be sent to service "B". The response coming from service "B" is indexed for search. The proxy is created programmatically using the ChannelFactory.
When service "A" takes less than 10 minutes, the calls to service "B" are successfull. But when service "A" takes more time (~20 minutes) the calls to service "B" throw the following exception:
Exception Message: An unsecured or incorrectly secured fault was received from the other party. See the inner FaultException for the fault code and detail
Inner Exception Message: The message could not be processed. This is most likely because the action 'namespace/OperationName' is incorrect or because the message contains an invalid or expired security context token or because there is a mismatch between bindings. The security context token would be invalid if the service aborted the channel due to inactivity. To prevent the service from aborting idle sessions prematurely increase the Receive timeout on the service endpoint's binding.
The binding settings are the same, the time in both client server and web service server are synchronize with the Windows Time service, same time zone.
When i look at the server where web service "B" is hosted i can see the following security errors being logged:
Source: Security
Category: Logon/Logoff
Event ID: 537
User NT AUTHORITY\SYSTEM
Logon Failure:
Reason: An error occurred during logon
Logon Type: 3
Logon Process: Kerberos
Authentication Package: Kerberos
Status code: 0xC000006D
Substatus code: 0xC0000133
After reading some of the blogs online, the Status code means STATUS_LOGON_FAILURE and the substatus code means STATUS_TIME_DIFFERENCE_AT_DC. but i already checked both server and client clocks and they are syncronized.
I also noticed that the security token seems to be cached somewhere in the client server because they have another process that calls the web service "B" using the same service account and successfully gets data the first time is called. Then they start the proccess to update the office sharepoint server search service indexes and it fails. Then if they called the first proccess again it will fail too.
Has anyone experienced this type of problems or have any ideas?
Regards,
--Damian
10 mins is the default receive timeout. If you have an idled proxy for more than 10mins, the security session of that proxy is aborted by the server. Enable logging and you will see this in the diagnostics log of the server. The error message you reported fits for this behavior.
Search your system diagnostic file for "SessionIdleManager". If you find it, the above is your problem.
Give it a whirl and set the establishSecurityContext="false" for the client and the server.
Don't call the service operation in a using statement. Instead use a pattern such as...
client = new ServiceClient("Ws<binding>")
try
{
client.Operation(x,y);
client.Close();
}
catch ()
{
client.Abort();
}
I don't understand why this works but I would guess that when the proxy goes out of scope in the using statement, Close isn't called. The service then waits until receiveTimeout (on the binding) has expired and then aborts the connection causing subsequent calls to fail.
What I believe is happening here is that your channel is timing out (as you suspect).
If I understand correctly, it is not the calls to service A that are timing out, but rather to service B, before you call your operation.
I'm guessing that you are creating your channel before you call service A, rather than just in time (i.e. before calling service B). You should create the channel (proxy, service client) just before you use it like:
AResponse aResp = null;
BResponse bResp = null;
using (ServiceAProxy proxyA = new ServiceAProxy())
{
aResp = proxyA.DoServiceAWork();
using (ServiceBProxy proxyB = new ServiceBProxy())
{
bResp = proxyB.DoOtherork(aResp);
}
}
return bResp;
I believe however, that once you get over that problem (service B timing out), you'll realize that the sharepoint app's proxy (that called service A) will timeout.
To solve that, you may wish to change your service model from a request-response, to a publish-subscribe model.
With long-running services, you'll want your sharepoint app to subscribe to service A, and have service A publish its results when it is ready to do so - regardless of how long it takes.
Programming WCF Services (O'Reilly) by Juval Lowey, has a great explanation, and IDesign (Juval's company) published a great set of coding standards for WCF, as well as the code for a great Publish-Subscribe Framework.
Hope this helps,
Assaf.
I actually triggered this error just now by doing something silly. I have a unit test that modifies the system date in order to test some time-based features. And I guess the apparent time difference between when I created the context and when I called my method (because of the changes to the system date), caused something to expire.