| bio | website | astralissolutions.com |
|---|---|---|
| location | Lafayette, LA | |
| age | 27 | |
| visits | member for | 1 year, 11 months |
| seen | Mar 26 at 13:59 | |
| stats | profile views | 8 |
There's no place like ::1.
|
Nov 21 |
comment |
ListItem Update from Client Object Model Not Triggering OnWorkflowItemChanged Activity I'm afraid this approach didn't prove at all fruitful in any of my testing. |
|
Nov 21 |
comment |
ListItem Update from Client Object Model Not Triggering OnWorkflowItemChanged Activity In my case I was able to parse the name I gave the file in my web service to get the bare minimum data I needed and used it to retrieve the rest from a database. It was a contrived solution but it worked around the problem I was having. There was only so much intellectual ping-pong I had time to play with because of looming deadlines. |
|
Nov 21 |
comment |
ListItem Update from Client Object Model Not Triggering OnWorkflowItemChanged Activity This is interesting. I'll be sure to check it out. |
|
Nov 20 |
accepted | ListItem Update from Client Object Model Not Triggering OnWorkflowItemChanged Activity |
|
Nov 20 |
comment |
ListItem Update from Client Object Model Not Triggering OnWorkflowItemChanged Activity I got similar sentiments from a reply on StackOverflow. This may be a bug in the process model for SharePoint workflows that results in a race condition in detecting the first change event. I've elected to move my code inside the workflow proper. I don't like the solution, but trying to wait out a race condition is too non-deterministic for my tastes. It does appear, however, that a thread sleep could have some efficacy in resolving the problem. |
|
Nov 16 |
asked | ListItem Update from Client Object Model Not Triggering OnWorkflowItemChanged Activity |
|
May 3 |
awarded | Commentator |
|
May 3 |
comment |
Managed Account Password Is Being Unintentionally Changed in Service Configuration If you're in Geneva, that may require something a bit after your normal hours as my time is UTC -6. :) |
|
May 2 |
awarded | Benefactor |
|
May 2 |
comment |
Managed Account Password Is Being Unintentionally Changed in Service Configuration Thanks for sticking with the problem. I'm awarding the bounty your way, but unfortunately still haven't been able to quite resolve the issue. |
|
Apr 28 |
comment |
Managed Account Password Is Being Unintentionally Changed in Service Configuration There is no one else who can change it for me. I'm actually doing custom development for this deployment but my small company's one sysadmin is not very experienced and hasn't taken the time to flesh it out himself. If the solution to the problem was to get someone else to do it, I wouldn't have posted my question. If you mean use a different account to do it, there are no accounts with permissions elevated any higher than the ones I'm logged into, so there is a problem with the service configuration that I am uncertain how to rectify. |
|
Apr 28 |
comment |
Managed Account Password Is Being Unintentionally Changed in Service Configuration The account is already a managed account. Please see the update above. It is not currently possible to initiate a password change from SharePoint given the current system configuration due to permissions restrictions. |
|
Apr 27 |
comment |
Managed Account Password Is Being Unintentionally Changed in Service Configuration If you could elaborate on the process, I could test this. However, I do not see any options to update account passwords in this panel, including in any of the configurable services that utilize the account. |
|
Apr 27 |
comment |
Managed Account Password Is Being Unintentionally Changed in Service Configuration No, it does not. |
|
Apr 27 |
revised |
Managed Account Password Is Being Unintentionally Changed in Service Configuration added 1281 characters in body |
|
Apr 27 |
revised |
Managed Account Password Is Being Unintentionally Changed in Service Configuration added 1281 characters in body |
|
Apr 27 |
comment |
Managed Account Password Is Being Unintentionally Changed in Service Configuration The converse is true. What is happening is that the password in Active Directory remains unchanged, but the configuration for the SharePoint Timer Service is updated by some automated process to reflect a new password that was never set. As a result, the service does not start automatically, and we are forced to go into the service configuration and change the password back to its original state to start the service. Once resetting the service configuration, the timer service starts normally. |
|
Apr 27 |
comment |
Managed Account Password Is Being Unintentionally Changed in Service Configuration The account was specifically created when we set up the server (and named sp_db_user to indicate its purpose), and in general, there's very little work done on the client's domain. The farm environment is less a farm and more a dedicated web server for the client. It is not in use elsewhere. |
|
Apr 27 |
comment |
Managed Account Password Is Being Unintentionally Changed in Service Configuration @VedranRasol I've already checked the information at the technet article, but re-checked it again just now to be thorough. Regarding whether or not auto-pass-reset is visible, I can't follow your navigation tree to anywhere in Central Admin. I can tell you that automatic password reset is not actively configured for that account, as I mentioned. Regarding changing the password, I'm actually receiving an Access Denied alert when attempting to do so. |
|
Apr 25 |
awarded | Promoter |