Permissions / cant modify job time

Hello,

We are having a weird issue. It seems that the users group needs some sort of write permission to the c:\24x7 folder and if it does not have that permission we get errors as well as not being able to modify the job times in the web console. It reverts job times back to 00:00

When we grant the users group "write" permissions to c:\24x7 we can launch the desktop scheduler and change job trimes in the web console BUT we get flagged by our security software for allowing users to write to c:\24x7 and c\24x7\bin

Can you give us best practices on how to permission the folders?

If Windows UAC is enabled, group permissions don't have any impact on the folder access. You need to give explicit permission to the account running the scheduler. If you also allow users to run it in graphical desktop mode, then also to every user who runs it.

	SysOp wrote:
	If Windows UAC is enabled, group permissions don't have any impact on the folder access. You need to give explicit permission to the account running the scheduler. If you also allow users to run it in graphical desktop mode, then also to every user who runs it.

I have done this and its still an issue if UAC is enabled on the servers which is a policy in my organization.

the 24x7 service is running as local system. I gave local system + all the users explicitly full control on the c:\24x7 directory. Is there anything else i can to do resolve this?

I'd like to clarify the setup.

If you have the 24x7 running as a service using LocalSystem account, and you use the 24x7 web console to connect to it and make the changes, the changes are made actually by the service using the local system account, and so UAC is not a factor and doesn't interfere in this case.

But if you remote desktop to the server, and start 24x7 in the desktop mode, you run it under your own account, and all the changes you make are saved using your account, which is a subject to UAC restrictions.

SysOp wrote:

I'd like to clarify the setup.

If you have the 24x7 running as a service using LocalSystem account, and you use the 24x7 web console to connect to it and make the changes, the changes are made actually by the service using the local system account, and so UAC is not a factor and doesn't interfere in this case.

But if you remote desktop to the server, and start 24x7 in the desktop mode, you run it under your own account, and all the changes you make are saved using your account, which is a subject to UAC restrictions.

We run this under the web console. When I disable UAC the problem goes away but once the GPO enables itself again. The problem returns... Now this is only an issue when we need to modify a job but i would like to find a working solution to this.

The 24x7 Scheduler and the Web Console are both running under "Local Service". We login to the web console using our active directory credentials.

Thank You

Per Microsoft docs, LocalSystem has complete access to the local system and UAC cannot do anything about it.
https://docs.microsoft.com/en-us/windows/win32/ad/the-localsystem-account

Are you sure it's actually .\LocalSystem and not some other domain account with similar spelling?

Are the files located on a network share mapped using some other account by any chance?

	SysOp wrote:
	Per Microsoft docs, LocalSystem has complete access to the local system and UAC cannot do anything about it. https://docs.microsoft.com/en-us/windows/win32/ad/the-localsystem-account Are you sure it's actually .\LocalSystem and not some other domain account with similar spelling? Are the files located on a network share mapped using some other account by any chance?

Yes it is running as Local System.

Can you explain what you mean by"are the files located on a network share"?

The scheduler is calling .Net batch applications on the local E:\ drive of the server. The 24x7 scheduler and web console run from C:\

i am unable to upload a screenshot due to out web filtering policy[/img]

There are couple of thinks you can check to get more details which could help with pinpointing the root cause.

1. If you don't already have files access auditing turned on on your windows server, please consider enabling it. The windows security event log will show all access denied events with details which may include the reason and subsystem that blocked it.

2. Use Microsoft's utility Process Monitor to monitor file access. This could be a bit tricky because you need to monitor all a process (job processes are kicked of at a later time, you can't preselect them). On a busy server that may prove difficult, but as a benefit, you would be able to monitor registry access and other types of events that also may show additional problems.