Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.6K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 298 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 259 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Outlook Sync fails without Windows admin rights
afarr
Member Posts: 287
One of our clients (NAV 2009 SP1, Classic, SQL) has Outlook Sync set up, connecting by Web Services. NAV is installed on a single server, and the users connect to it via terminalservices. When a user is given admin rights on the server, they can sync with Outlook, but when admin rights are removed they get an error message saying:
“The connection to Microsoft Dynamics NAV database failed. The program returned the following error: Configuration system failed to initialize. Verify your synchronization settings"
Even with sysadmin rights in SQL, the problem is still there. It's only with Windows admin rights (which of course we don't want to give to users) that the Outlook sync works.
What can we do to resolve this?
“The connection to Microsoft Dynamics NAV database failed. The program returned the following error: Configuration system failed to initialize. Verify your synchronization settings"
Even with sysadmin rights in SQL, the problem is still there. It's only with Windows admin rights (which of course we don't want to give to users) that the Outlook sync works.
What can we do to resolve this?
Alastair Farrugia
0
Comments
I'd try giving users local admin rights to the terminal server. If that doesn't work, it might be an issue "roaming" users config files:
http://social.msdn.microsoft.com/forums ... 1500deb0a/