|
 Posted 4/13/2007 1:33:15 PM |
| | | Forum Moderator: Please help. This is a chronic issue with c360 for my company. It is useless to us until it is resolved. I have worked with Brume multiple times, reinstalled the application, and applied the most recent patch. This is what displays on the troubleshoot.aspx page... "MatchCodeGenerator Service Account Permission
An error occurred while verifying permission of account with which MatchCode Generator Service is running. See event viewer for details." I have verified that the Active Directory account that is running the service has enough permissions. |
| | Posted 4/17/2007 2:23:42 PM |
| | | I have same issue with their support...extreme slow to react... I think the patience is the only solution here... I have problem of their database setup script, guess how long I wait to get a script... At end, I must hack the Database, and extract the script myself....
Nick
RRU.ES.IS |
| | Posted 4/17/2007 2:31:11 PM |
| | | Also, to solve your problem, try this which is ours solution The user who start the service is "YourDomain\mscrmadmin" --who is the default admin account for MSCRM "YourDomain\mscrmadmin" now is the member of "Domain Admin", also the local machine admin for the MSCRM server Also, "YourDomain\mscrmadmin" should be the user that installed the c360, and be the dbowner for c360_solution Hope it helps
Nick
RRU.ES.IS |
| | Posted 4/18/2007 10:38:12 AM |
| | | Another thing... The warnings or errors in Event log (Applicaition) are also very userful. The DupDection service running at backgroud, normally would generate a useful exception logs and it would be very helpful if you post it here, I can help u take a look Good luck 
Nick
RRU.ES.IS |
| | Posted 4/20/2007 9:33:18 AM |
| | | Still not working. I just used the same account to reinstall c360 and own the MSCRM and c360_Solutions databases. I was told by my account manager, Pamela Umunna, that a forum moderator would reply to me on here. One week has gone by since I started this thread with no reply from a moderator. I'm really dissapointed in c360 customer service. This depreciates my opionon of c360 and whether I would ever want to purchase another c360 product. Unless I'm shown otherwise I'll assume that c360 doesn't value their customers. |
| | Posted 4/20/2007 2:48:39 PM |
| | | I feel sorry for you and me...I'm the guy who pushed to purchase their product and find out the lacking of the support latter... Anyway, Hope they could contact you ASAP, or maybe there are just 2 busy to show their latest products and forget their old users
Nick
RRU.ES.IS |
| | Posted 4/20/2007 4:13:35 PM |
| | Chris,
My name is Ken Champion, and I am the new Technical Support Manager for c360 Solutions. First, let me apologize for not resolving this issue to your satisfaction. Please understand that the purpose of our forum is to exchange ideas and solutions with fellow users of our products. While the c360 support team does monitor the forum, they typically do not create support cases from it. The forum is not the most efficient method for obtaining time-sensitive assistance from us. However, if you email support@c360.com, the support team will be made aware of your case. I will also be alerted. Going forward, if you experience delays beyond our stated service levels, please contact me at ken.champion@c360.com, and I will be happy to take action. Now back to your case: our VP of Software Development researched the case on 04/16 and determined that the issue was related to the permission configuration. He stated that the symptom could be recreated by attempting to log in to SQL server directly with the “Duplicate Detection” user. This would indicate that this specific problem seems to be outside of the c360 software itself. I posted his notes into this message for your review. Again, I apologize for any misunderstandings. Ken
DEVELOPMENT NOTES:
This is a known issue – 0x5 means Permissions Denied.
Most common cause is that the account which they use to connect to the SQL Server (a native SQL account) is not a member of the sysadmin fixed role. When SQL native login is used we make a call to SETUSER ‘username’ to set the context. For this call to complete the login used to log in must be a sysadmin fixed role.
This could also happens when the SQL Server service is running under a domain account and that domain account does not have enough permissions to query the AD for a particular principal (US\[firstname.lastname] in this case).
Check to make sure the SQL Server service is not running under a domain account and switch it to LOCAL SYSTEM if possible. If that’s already the case or if the customer does not want to do it, then they have to grant that particular domain account enough permissions to the AD subtree so that it can read necessary information.
You can show the error to the customer just by logging in to the SQL server with exact same user they use for dupdet and running SETUSER ‘[validusername]’. It should fail with the same error.
Ken Champion
c360 Technical Support Manager
|
| |
|