Posts Tagged ‘permissions’

Delete WINDOWS.OLD on Windows Server

Posted: October 5, 2014 in Information, Server 2012, Windows General
Tags: , , ,
6

After performing an in-place upgrade on a Windows machine, you will find a WINDOWS.OLD folder in the root of C:. This folder will have a backup of your old program files, appdata and Windows folder… just in case you need to revert back or recover something that might have been lost during the upgrade. When you try to delete it though you are told you don’t have permissions. (more…)

Orchestrator 2012 Web Console shows no details

Posted: February 28, 2013 in Orchestrator, Solved
Tags: , ,
1

On a brand new System Center Orchestrator 2012 install the web console was showing the basic site, but would show no details for Runbooks or Runbook Servers.

It would work fine if I connected using the “Orchestrator Admin” account used during install, but other accounts were all having problems. It seemed obvious that permissions were the problem, but where exactly? All those same users could use the Orchestrator Designer console without any problem, so it seemed they had all the permissions needed.

(more…)

Orchestrator 2012 Web Console permissions do not reset

Posted: February 28, 2013 in Orchestrator, Solved
Tags: ,
0

Have found an issue when using the Orchestrator Web Console where the permissions a user has are still active after they have been removed.

Scenario:

  1. Permissions are granted to an AD group to a runbook folder using the Designer console
  2. User is added to the AD group
  3. User can connect to Designer and also the Web Console to see and manage the runbooks in that folder
  4. Remove the user from the group
  5. In Designer, the user no longer has access and cannot see the folder or runbooks
  6. In the Web Console, the permissions are unchanged and the user can still view and manipulate the runbooks

Suggestions provided through a post to the technet forums suggested that the permissions are cached in the SQL database in the “Microsoft.SystemCenter.Orchestrator.Internal.AutorizationCache” table, however this table was already empty

Restarting the Servers, services, logging the user off and on etc made no difference. The permissions still persisted the following day.

Another user suggested this is a known bug and that they resolved it with a call to Microsoft. I can find no other mention/reference of this bug, so a call to Microsoft it is…

(more…)