Why would I be seeing the app pool account changing a Support Group value in the WI history?

Leigh_Kilday

I've had somebody ask me who reassigned an IR. The history shows that the app pool service account performed this action. Under what circumstances would this occur? We really need this sort of thing to be attributed to a person.

Brett_Moffett

We have been unable to re-produce this in our test lab, but that is assuming many things (Data, Customizations etc. etc.)
I agree with @Nicholas_Velich that you should log a support call for this one and work through an elimination of variables to lock down what is causing this issue.

For anyone else reading this post, Please let us know if you are also experiencing this issue as we would like to track how wide spread this is or if there is common thread that links the cases.

Keep an eye out here for a future fix.

Brett_Moffett

I have just tested several different ways of changing the assignment via the portal and none of them have used the AppPool account.

• Is the AppPool account used anywhere else? (Workflow account, Orchestrator etc.)
  There may be some automation that is doing this task that is using the same account as the AppPool.
• Do you have workflows that automatically assign IR's to users based on rules?
  The Workflow account might be the same account as the AppPool and this could be causing it.
• Do you use any of the assignment tools, such as Group Assign?
  These shouldn't use any additional accounts, but it would be interesting to see if this is the source of these issues.

If you can test assigning and re-assigning the IR to different Analysts it should narrow down the search.

Leigh_Kilday

We have separate accounts for the workflow service and Orchestrator, no runbooks or SCSM workflows that reassign IRs, and nobody but admins have access to the console.

I reassigned a IR just now via the portal IR form and noticed the app pool account is being used again. I also assigned it to an analyst so there's a history entry attributing that action to me, but not for the Support Group.

Brett_Moffett

What version of the portal are you running?
How are you reassigning the user? (Manual search on the form, Group Assign task, Assign to me task etc.)

Leigh_Kilday

We're running 5.0.8.

99% sure I used the controls on the form (manual) and not the Assign to Analyst by Group task.

Nicholas_Velich

Hi Leigh,

I have recently encountered similar intermittent behavior in one of my customer's environments and created an Incident with Support, so you are not alone!

If you have not already done so, please create an Incident at support.cireson.com.

Thanks,
Nick

Leigh_Kilday

Will do. Thanks Nick.

Brett_Moffett

We have been unable to re-produce this in our test lab, but that is assuming many things (Data, Customizations etc. etc.)
I agree with @Nicholas_Velich that you should log a support call for this one and work through an elimination of variables to lock down what is causing this issue.

For anyone else reading this post, Please let us know if you are also experiencing this issue as we would like to track how wide spread this is or if there is common thread that links the cases.

Keep an eye out here for a future fix.

Aaron_Boock

Do you use Windows or Forms authentication?  I've seen this happen with Windows authentication where the session itself must timeout, then uses the web service account to apply changes etc.

Thomas_Stromberg

I have seen this on a customer also. They are using windows authentication. I have not found a way to replicate it but it occur sometimes. 

John_Long

Also encountering this. When an analyst completes a manual activity, the history for that MA shows the SCSM Portal service account as the user initiating the actions, rather than our analyst.

David_Sebba

We are seeing this on-and-off as well.  It's not consistent, but it is clustered (so it happens over a morning, or a day, then stops).  The Action Log records "Post_EnteredBy_93521833_D998_8788_E0C6_7DC5A63D0C21" correctly as the analyst, but the EntityTransactionLog shows the service account under "ContextGenerated".  In our case, this is affecting the Notify Analyst app, since the assignment actions are recorded under the service account instead of the analyst's account, they are being notified when self-assigning tickets.

Eugene_Rack

I have also just seen this issue. The history log shows that the Portal Service Account changed the support group. The only orchestrator runbook that changes support group are for a specific IR ticket none for Service Requests and the Orchestrator has it's own service account it runs under. 

Tom_Hendricks

Also seeing this.  We use Windows Auth, and when the current user times out, the App Pool ID becomes the user of record for any activity.

I do not love this behavior and would rather see the session time out, even if it means having to refresh the user's session somehow.  Should I open a support ticket or create a feature request for this?  (i.e., is this by design or a bug?)

David_Sebba

It's a bug with the Portal that support has acknowledged and said a fix is coming (at least, they acknowledged it to me).

It also affects the Notify Analyst App.  If someone self-assigns a work item, and it's logged under the service account, they are notified that they have a work item assigned.

Leigh_Kilday

Tom_Hendricks said:

Also seeing this.  We use Windows Auth, and when the current user times out, the App Pool ID becomes the user of record for any activity.

I do not love this behavior and would rather see the session time out, even if it means having to refresh the user's session somehow.  Should I open a support ticket or create a feature request for this?  (i.e., is this by design or a bug?)

Cireson devs have told me that they are already working on a solution for this, and that may be a session timer.

Between users losing unsaved work and the app pool account incorrectly named as the actor, I'd pick the former.

Tony_Collett

Hi all, 
Just want to chime in here to say that this is a known error and is currently in the process of being fixed. I do not have an ETA for when the fix will be available at this stage. 
There is a workaround you can try if you are having this issue, switch your authentication method from Windows Auth to Forms Authentication. This will time out users appropriately and send them back to the login screen. 
Sorry for the inconvenience caused by this issue. 
Regards, tony

Tom_Hendricks

Leigh_Kilday said:

Between users losing unsaved work and the app pool account incorrectly named as the actor, I'd pick the former.

If those were the only two options, I think I would have to agree with @Leigh_Kilday.  Where there is a timeout, typically there is a timer and a way to perpetuate the session.  I did not give any hint to that in my last post (my mistake), but it was on my mind as I wrote it.  Obliterating unsaved work at a mysterious and unannounced time would be terrible for users.  On the other hand, being able to positively identify who is making edits to work items is a non-negotiable compliance issue for some businesses.

You mentioned that a session timer may be in the works.  I would definitely vote for that.  At a company I used to work for, one of our clients required a 15-minute inactivity timeout (yes, 15!) for all users.  Let's just say this was not a top feature request for users.  What made it tolerable was having a countdown clock on the screen at all times and placing a refresh button below it, which would renew the session even if no changes were being made.  Users often needed to read the screen for quite a bit longer than 15 minutes before they would take any actions, which would have let their session time out if that button was not available.  So while the timeout was not a popular feature, it served a necessary purpose and everyone got used to it fairly quickly due to the way it was implemented.

All parts of that code were simple, except for the countdown clock in the UI.  It was not easy getting it to match the actual time remaining in the user session on the server, which was the component that actually timed out, but it was very close.

Also, thanks for the official update, @Tony_Collett.  I wanted to share this anecdote in case it either supports what is being done already or provides anything useful to that process.

Eugene_Rack

For some reason it appears that one of our Analysts AD account when logged on, any update they make in the Portal would appear to come from the Portal service account even though they are logged with their own AD account as an analyst. I tried updating their AD account and restarting the cache builder. This has now caused an issue with his account in the portal. The analyst can open the portal and see all the tasks, like Mywork, Teamwork, Active work, etc, as an Analyst would. However he cannot create on-behalf off, or update any tickets. Appears that he has a partial Analyst access. Anyone else seen this.

Eugene_Rack

Issue above all sorted.

Conner_Wood

@Eugene_Rack I'm assuming you cleared the Cireson DB cache to fix that issue you mentioned.  It's a good idea and potentially helpful to others to state what the fix is or what appears to be the fix or even if you don't know.

Eugene_Rack

@Conner_Wood Sorry about the previous short answer. Yes I ran the Cireson  DB recommended command  against the ServiceManagement  db. This appears to have resolved the issue. 

David_Darling

Is anyone still running into this issue even on v7 w/ the Session Timer enabled and configured appropriately?  We are, and have an IR open w/ Cireson Support as such.  Here's the SQL we're running against the ServiceManager DB to look out for occurrences (of course, some occurrences are normal, but we're still seeing simply updates made to Work Item properties associated with the AppPool ID periodically -- and as soon as a user starts experiencing the issue, it stays with them until we recycle the app pool):

SELECT ECL.EntityChangeLogId, CASE WHEN ECL.RelatedEntityId IS NULL THEN 'Object' ELSE 'Relationship' END AS 'Type', CASE WHEN ECL.ChangeType = 0 THEN 'Add' WHEN ECL.ChangeType = 1 THEN 'Update' WHEN ECL.ChangeType = 2 THEN 'Delete' WHEN ECL.ChangeType = 3 THEN 'Staged' ELSE CONVERT(VARCHAR, ECL.ChangeType) END AS 'ChangeType', BME.DisplayName AS 'EntityDisplayName', CASE WHEN ECL.RelatedEntityId IS NULL THEN MT.TypeName ELSE RT.RelationshipTypeName END AS 'EntityOrRelationshipType', ECL.SubscriptionSpecific, ETL.ContextGenerated, ECL.LastModified AS 'LastModified' FROM EntityChangeLog ECL LEFT OUTER JOIN EntityTransactionLog ETL ON ECL.EntityTransactionLogId = ETL.EntityTransactionLogId LEFT OUTER JOIN ManagedType MT ON ECL.EntityTypeId = MT.ManagedTypeId LEFT OUTER JOIN RelationshipType RT ON ECL.EntityTypeId = RT.RelationshipTypeId LEFT OUTER JOIN BaseManagedEntity BME ON ECL.EntityId = BME.BaseManagedEntityId WHERE ContextGenerated = '<YOUR APPPOOL ID HERE>' ORDER BY ECL.EntityChangeLogId DESC