We have multiple instances for our poject like Sandbox, Staging and Live. They are behaving differently on Contract lines.
In staging on the contract line end date, the lines are getting expired.
But this is not happening in Sandbox and live, what might be the reason?
And we observed that on the contract lines in Staging the
Total Cases/Minutes is setting to 1 on expiring but this is not happening in PROD and Sandbox. And if we are manually placing it in there it is reseting it to ZERO.
Can any one say why this is happening..?
Thanks
The issue is with the asynchronous activities in CRM Service/Server, they are getting failed because of some reason.
Related
About six months ago I contacted Microsoft support because when I did Continuous Delivery I would get error messages from every server it had once been on, that it failed. (five or six messages each time)
Since it was not supposed to actually deploy to any of those servers that were no longer being used, I contacted Microsoft support.
They were unable to figure out the cause, despite an email chain to me that was at least 35 responses deep.
So, they disabled CI for my repository.
Not a great solution, but I no longer needed to worry about my code being deployed to random servers.
However, today, even though have not enabled CI configuration I again received a message that it had attempted to deploy and failed.
So, if Microsoft can't fix this CI issue, what is my next step?
EDIT: Well, it looks like the one failed deployment was a fluke as I have since checked in twice more, and I havent received any emails indicated a failed deployment.
I have since pushed a build twice more and it did not happen again. So random error I guess.
I've got a pipeline that logs in and logs out off a web-application every 5 minutes to ensure that the apps backend works, the database is up...
There occurred a problem that was not even related to the app directly, and my boss was bombarded with email-notifications. Is it possible to limit the emails that notify of a series of broken pipelines to only one, and suppress all subsequent emails until the pipeline has been fixed?
It seems that the editor for "Pipelines emails" is rather limited and doesn't support this directly. However, this option exists in Jenkins, and I'm wondering if someone figured out a solution or a workaround to achieve this in Gitlab CI. (Is it possible to script something like this in the ".gitlab-ci.yml"-file?)
In the past (2017) we have completed the required AATS testing scenarios and completed them successfully. The IRS has subsequently moved our TCC to production and have been filing in 2017 and 18 without issue.
My company is in the process of rebuilding its SOAP application and would like to run a number of test scenarios of our own to help validate some logic as well as a few edge cases – Are we able to send data to AATS (using IRS name controls) to read the IRS responses?
Yes you should be able to still transmit over the AATS service, you'll just need to switch over the required pieces of information like the endpoint and TCC. I still occasionally use AATS on my local copy of our service to test any issues that people bring up.
I have a main incoming mailbox in CRM (sort of like a contact#organisation.com address) but for some reason today, the mail has stopped flowing into CRM.
I have tried resetting the async services as mentioned here: https://community.dynamics.com/crm/f/117/t/159892
But the mailbox remains stuck.
I have also tried enabling tracing on the backend servers but even have 20 minutes I didn't find any issues in the trace logs...
EDIT
So the process completed at 4am this morning and I can't work out why the test took over 17 hours to complete without error.
What is odd is all the async jobs ran yesterday (in a timely matter) without issue and I did not find any errors related to this email issue in the trace logs.
I am concerned with why this process took so long without any indication of an issue and I would be happy for someone to raise some suggestions
I observe the following weird behavior. I have an Azure web role which is deployed on love Azure cloud. Now I click "Configure" in the Azure Management Portal and change the number of instances - the portal shows some "activity". Now I open the browser and navigate to the URL assigned to my deployment and start refreshing the page something like once per two seconds. The page reloads fine many times and then fro some time it will stop reloading - the request will be rejected, then after something like half a minute the requests are handled normally.
What is happening? Is the web server temporarily stopped? How do I change number of instances so that HTTP requests to the role are handled at all times?
When you change the configuration file, your current instance might be restarted. This might be the reason you met with, which your website didn't response in about 30 seconds.
Please have a look http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.serviceruntime.roleenvironment.changing.aspx and check if it 's because of the role restarting.
What you are doing is manual. Have you looked at the SDK for autoscaling Azure?
http://channel9.msdn.com/posts/Autoscaling-Windows-Azure-applications
Check out the demo at the 18 minute mark. It doesn't answer your question directly, but its a much more configurable/dynamic way of scaling Azure.
Azure updates your roles one update domain at a time, so in theory you should see no downtime when updating the config (provided you have at least two instances). However, if you refresh the browser every couple of seconds, it's possible that your requests go always to the same instance due to keep-alive.
It would be interesting to know what the behavior is if you disable keep-alives for your webrole. Note that this will have a performance impact, so you'll probably want to re-enable keep-alives after the exercise.