Announcement visibility

Tomi_Kaartama

In another discussion, the following was written:

Domain users will work once its enumerated in the cache, groups are only enumerated in the cache if its targeted to one of the below settings:

- Mapped within Support Group Mappings

- Already in use in a current role:  Analysts, KnolwedgeManager, AssetManager, LocalizationManager

- A Security Group

- A specified Team Group

- A specified Group Form

- Announcement Group 

We have a situation where

- A group can be selected as the access group for an announcement which means it is present in service manager
- The group is defined as security group in AD
- The announcement is still not visible for group members

What exactly "a security group" means in the top list? Is that something different than a group created in AD as a security group?

What would I need to do to allow posting the announcement to this group?

T: Tomi

Nicholas_Velich

Hi Tomi,

By design, the CacheBuilder does not calculate membership of all AD groups in the SCSM environment. For performance reasons, the CacheBuilder only caches membership of groups it knows it needs to use somewhere in the application. The groups the CacheBuilder needs to cache can come from a variety of locations, as you indicated in the initial post (announcements, navigation nodes, support groups, etc.).

As far as how to identify these groups so they are pre-cached and available immediately, Brian is spot-on with his suggestion, and it is my recommendation as well:

"One thing I was provided is if you have large groups you may want to target for a future issue is to create a backdate announcement that expired, target the group Team2. This will sync the members into the portal. So there is no lag when new announcements are posted."

Even if not visibly in-use (i.e. an active announcement, a visible Navigation Node/Folder, etc.), an AD group being specified in any of these locations should allow it to cache and be available.

As I think has already been noted, if an AD group is not specified and therefore not pre-cached, it can be added in any of the above locations and the CacheBuilder will calculate membership when it next hits that Scoped Access cycle (every 24 hours by default, but is configurable-- more info on CacheBuilder intervals can be found here). If you are in a pinch and need to hurry it along, the CacheBuilder does calculate this on restart as well.

I like Alex's suggestion to have a place to jot all of these groups in a list so they are already cached when you might need them. This would essentially have the same effect as the suggestion above, but might be easier to manage this way. I encourage you to open a feature request for that, and it could potentially be added in future releases.

Thanks,
Nick

Brian_Wiest

Ran into the same issue as well.

What it means if lets you have have AD security groups
Ciresonportalusers -Linked to an end user role 
Ciresonportalanalysts -Linked to the analyst role
Team1 - linked to team groups
Team2 - listed in AD but not "targeted" in SCSM/Cireson settings

Lets say you want to publish an announcement specifically to Team2. The create announcement will allow you to target the AD group and publish.
The issue you run into is that AD group membership is not replicated into the cache. Basically the portal knows the group exists but not the members. 
So once published the cache builder has to pick up the "requirement" to sync the members on the next sync cycle. If this group has a large membership it can take some time.
The end result is that publishing to a group like Team2 there is a lag before the members of that group will see the announcement on the portal, not instant like if you target Team1. 

One thing I was provided is if you have large groups you may want to target for a future issue is to create a backdate announcement that expired, target the group Team2. This will sync the members into the portal. So there is no lag when new announcements are posted.
HTH

Tomi_Kaartama

In fact, the group is small. I would want to publish to about 20 users that are end users but we don't want to publish to all end users.

Tomi_Kaartama

I re-read the suggestion. So our situation is what is described for Team2. I'll test that approach.

Tomi_Kaartama

So this does work. In our environment, the cache builder is performing a full update once a day. If all announcements are created well in advance, this should not be a problem.

But is there a more permanent solution for this? Is there a way to add all the groups that I would want to be always present to a list somewhere so that we would not need to wait for the cache builder?

One idea that comes to my mind is to create an empty folder on the support portal, then share it with all the different AD groups and finally hide it.

Would that work and/or is there a better way?

Alex_Marsh

The ability to flag certain groups for announcements (so membership is prepopulated in the database) would be a great help as there is often a delay (especially for urgent ones) for it to appear

Tomi_Kaartama

Does anyone at Cireson have any suggestion for this?

Nicholas_Velich

Hi Tomi,

By design, the CacheBuilder does not calculate membership of all AD groups in the SCSM environment. For performance reasons, the CacheBuilder only caches membership of groups it knows it needs to use somewhere in the application. The groups the CacheBuilder needs to cache can come from a variety of locations, as you indicated in the initial post (announcements, navigation nodes, support groups, etc.).

As far as how to identify these groups so they are pre-cached and available immediately, Brian is spot-on with his suggestion, and it is my recommendation as well:

"One thing I was provided is if you have large groups you may want to target for a future issue is to create a backdate announcement that expired, target the group Team2. This will sync the members into the portal. So there is no lag when new announcements are posted."

Even if not visibly in-use (i.e. an active announcement, a visible Navigation Node/Folder, etc.), an AD group being specified in any of these locations should allow it to cache and be available.

As I think has already been noted, if an AD group is not specified and therefore not pre-cached, it can be added in any of the above locations and the CacheBuilder will calculate membership when it next hits that Scoped Access cycle (every 24 hours by default, but is configurable-- more info on CacheBuilder intervals can be found here). If you are in a pinch and need to hurry it along, the CacheBuilder does calculate this on restart as well.

I like Alex's suggestion to have a place to jot all of these groups in a list so they are already cached when you might need them. This would essentially have the same effect as the suggestion above, but might be easier to manage this way. I encourage you to open a feature request for that, and it could potentially be added in future releases.

Thanks,
Nick