Yes there is progress being made, and hot fixes are being applied as they create the resolutions. I believe that there will be formal announcements made either today or tomorrow. Keep an eye out in your email box.
Right. The installer should do that, not us, IMHO.
I am not sure of the entire risk, but as @Mark_Wonsil said in response, this setting is very required, but also a highly sensitive security control that needs to be implemented with care. At Epicor we have regular security reviews (internal and 3rd party) where recommendations are made for hardening security. My guess is that this change came from one of those reviews.
But I also feel it is very unfair to say that with āevery releaseā you have āless and less controlā over your systems in the cloud so therefore this might sound like I am getting defensive, but so be it.
The past two releases we have been adding on what can be done with the cloud management portal, giving you more and more control. You can now deploy your own upgrades in pilot, and restart things, and copy live to pilot. In the very near future, you will be able to self upgrade your production system as well.
Me neither, since none was communicated. If I am a security manager I should be able to decide if an account needs impersonation or not, the way it has always been. Its painful to have to go to support, who have no idea about this, and instruct them to tell the cloud ops team to do it for me, and then wait for that entire communication cycle to complete. Itās not like any additional validation is happening here, its just adding more friction to the process. Something that should take 2 seconds now takes 2 days.
If its too risky to turn on, then I shouldnāt NEED to turn it on.
As a Zero-Trust proponent, a role should have the least-privilege to do the job and only elevate the privilege if needed. If thereās never a need to give a capability, why add the risk? Admins should seek less power, not more - IMHO.
![]()
Are these the same people that made the 12 hour MFA requirements for EpicCare???
Network EA had to add this requirement after report download security was tighten - only user owner of report or security manager could download it.
As the result this option was selected - use impersonation.
Now I donāt know what will be next with this new restriction . But if SM user is selected for EA it should work.
If you ask nicely support will turn this off for you, one of our customers led the way of this and I Iāve been able to get the same result ![]()
I am no longer seeing maintenance scheduled for this weekend 11/14 to upgrade Prod to Kinetic 25.2.5. Has this been delayed for the newly posted upgrade to 25.2.7 scheduled for 12/12?
I just submitted a ticket asking the same thing. Glad Iām not the only confused one!
Thatās where my headās at too. Iād rather see the mentioned run-as purposes behind something like an access scope. āRun-asā for reporting should only support reporting, MRP can only run MRP, etc. Depending on an entire maximum-privilege account for unattended impersonation is needlessly sketchy. If it exists, assume it will be exploited.
Like I said before, itās unusual to see this moved behind actual security. Unusual responses can indicate an event. Hopefully something like an auditor hollering WTH. But maybe not. Itās a good time to sit tight and let whateverās going on play out.
what so the context and predictive search bug is not being installed until middle of december ?
There is a communication going out shortly on the changes in the schedule. But yes, to confirm, the cloud update this weekend has been delayed and the new schedule is on epicweb: Kinetic in the Cloud 2025.2
Please watch for an incoming email due shortly.
Reviewed EpicWeb as well and now see this:
RESCHEDULED DATE: Friday, December 12 - Sunday, December 14: ANZ, Canada, MT/Express, Singapore, US Central, and US Gov Cloud datacenters
What a ride
Schedulers looking at customerās core staff vacation plans like

Peter
this is a right mess

