The Role-Based Administration documentation does not describe what the individual permissions actually control, and they are not self explanatory. For example, under Collection, you see several different 'modify' permissions and it isn't clear what they each control:

-Modify
-Modify Client Status Alert
-Modify Collection Setting
-Modify Folder
-Modify Resource

Please provide even a basic amount of information about what they control in the console. This will help prevent us silly sysadmins from just giving people tons of permissions so we don't have to reverse engineer what each of the settings does in order to let people do just what they need.

Thanks for your help!

Standalone Primary with Multiple SUPs - Documentation update

There is limited documentation on how to install and configure multiple SUPs in a Standalone Primary Site. It is advised to have all SUPs share the SUP DB when you have multiple SUPs in a Primary Site to reduce impact if a client changes SUP. However one of the SUPs will synch with MS Update while the others will synch with the one selected to synch to MS Update. Because of this the SUP configuration has to be the same for all SUPs and any SUP/WSUS maintenance needs to be carried out on only one SUP.

Wrong information in the article: https://technet.microsoft.com/en-in/library/gg682177.aspx

=================
Incremental Collection Updates

When you enable incremental updates for a collection, Configuration Manager periodically scans for new or changed resources from the previous collection evaluation and updates a collections membership with these resources, independently of a full collection evaluation. By default, when you enable incremental collection updates, it runs every 10 minutes and helps keep your collection data up-to-date without the overhead of a full collection evaluation.

When you create a new collection, incremental updates are disabled by default.

But by default, the value is now 5minutes as verified in SP1, R2, R2 SP1, 1511 and 1602

Could you please update the same

The guid https://technet.microsoft.com/en-us/library/mt651651.aspx is incorrect or missing some steps.

1. It mentions Endpoints a few times, while it has meen listener. Listener is not the same as endoint . AONAG must have a listener and the listerner name must the provided as sql server name


2. The port of listener must match the port of SQL Servers


3. BEFORE adding the DB to AONAG (if the new server is different than current one), run the following:

USE master

ALTER DATABASE cmXXX SET ENABLEBROKER
ALTER DATABASE cm_XXX SET TRUSTWORTHY ON;

USE CMXXX
EXEC spchangedbowner 'sa'

1. After adding the DB to AONAG, failover to secondary server(s) and run the following:

USE master
ALTER DATABASE cm_ps1 SET TRUSTWORTHY ON;

USE CMps1
EXEC spchangedbowner 'sa'

When I was moved my DB to AONAG, I also hvae many replication issues (I hvae moved a Primary Site DB). I needed to export and import CAS cert (on Primary and after failover to secondaries) and run exec spchangeuserslogin 'updateone','ConfigMgrEndpointUserCAS','ConfigMgrEndpointLoginCAS on all AONAG member servers.
I'm not sure if the last two steps was an accident, but I believe, that DB movement from standalone SQL to AGAON was done correctly (with preinst /stopsite and running setup). Of couse above was done on 1602.

We are trying to create a deployment for a package as below:

Start-CMPackageDeployment -CollectionName "WOL Testing" -PackageName "Powerdown" -DeployPurpose Available -DeploymentAvailableDay 02/05/2016 -DeploymentAvailableTime 10:50

- Findings as below:

Required Deployment with Schedule and Available Day and Time:

Start-CMPackageDeployment -StandardProgram -CollectionName "Brik" -PackageName "SMS Toolkit" -ProgramName "SMS" -AllowSharedContent $true -DeployPurpose Required -DeploymentAvailableDay 2016/11/01 -DeploymentAvailableTime 11:00 -ScheduleEvent AsSoonAsPossible

Available Deployment with available Day and Time:

Start-CMPackageDeployment -StandardProgram -CollectionName "1" -PackageName "SMS Toolkit" -ProgramName "SMS" -AllowSharedContent $true -DeployPurpose Available -DeploymentAvailableDay 2016/11/01 -DeploymentAvailableTime 11:00

- As the below options might be deprecated and new ones used please find the new commsnds as well:

Old : 'DeploymentAvailableDay' New: 'DeploymentAvailableDateTime'
Old : 'DeploymentAvailableTime' New: 'DeploymentAvailableDateTime'

Not yet introduced:

Old : -FastNetworkOption is not defined New:'DownloadContentFromDistributionPointAndRunLocally'

Old : -SlowNetworkOption is not defined New:'DownloadContentFromDistributionPointAndLocally'

- New Commands as below:

Required Deployment with Schedule and Available Day and Time:

Start-CMPackageDeployment -StandardProgram -CollectionName "Brik" -PackageName "SMS Toolkit" -ProgramName "SMS" -AllowSharedContent $true -DeployPurpose Required -DeploymentAvailableDateTime "2016/11/01 11:00" -ScheduleEvent AsSoonAsPossible -DownloadContentFromDistributionPointAndRunLocally

Available Deployment with available Day and Time:

Start-CMPackageDeployment -StandardProgram -CollectionName "1" -PackageName "SMS Toolkit" -ProgramName "SMS" -AllowSharedContent $true -DeployPurpose Available -DeploymentAvailableDateTime "2016/11/01 11:00" -DeploymentExpireDateTime "2016/12/01 11:00"

=============

It's quite frustrating to spend time logging bugs with ConfigMgr through Connect only to have bug submissions either incorrectly closed (i.e. closed as a duplicate but also closing the referenced bug - will it ever get looked at if all active bugs are closed!?) or being closed as fixed but not adding any information as to what the fix is or when the fix will be released.

Myself and colleagues spend the time and effort documenting these bugs with your products on behalf of customers so the very least that could be done in return is to let us know what is happening with them and ensure that this is communicated back to the person raising the bug.