i am unable to Start Profile Synchronization in sharepoint 2010 from central admin
due to which the Compile Audiences does not work
an error message pop up when i click on Start Profile Synchronization
" " can not navigate to the requested page while user profile synchronization is running please wait for current synchronization run to finish. ""
please help regarding this problem
thanks in advance
this problem occurred in windows 7 how ever it worked fine with Server2008
The way i understand it, when you install sharepoint 2010 on your desktop (Windows 7), certain components are very picky about how they are installed (user profiles sync), and some just wont install (FAST search).
This is pretty much the reason i stuck with creating vm's for development.
The best way to resolve this is, open the Forefront Identity Manager 2010 and check for the actual failure. Most of the cases you get problems because of the user trying to connect to AD do not have replication directory changes access.
Take a look at this post:
http://sharepoint-2010-world.blogspot.com/2011/02/cannot-navigate-to-requested-page-while.html
Related
Recently my web server (windows server 2012 R2) got several Windows updates. Since then I am not able to run a code involving RestSharp. It fails whenever I try to initialize "new RestRequest()". Windows event log registers this error: "User does not have permission to run the resource"
I have development environment with Windows 7 where I don't see these updates. My code runs fine.
I have looked into the update history on the server and looks like the following updates may be creating these problems.
KB3074548
KB3074228
KB3074545
I have looked into documentation of RestSharp to find out whether any specific permission needed on the application pool running RestSharp code. I could not find out anything.
I am wondering whether anyone else having this problem and/or may have any knowledge about permissions required to run RestSharp request.
Really appreciate any help.
It is now working. It was just a deployment issue.
I receive the following error message about 50% of the time when trying to publish an InfoPath 2010 form template to my corporate SharePoint site:
The image text reads:
Infopath canot save the following form: https://sharepoint.site.com/home/subsite/form_library
This document library was either renamed or deleted, or network problems are preventing the file from being saved. If this problem persists, contact your network administrator.
The thing that is odd about this is that I can resolve the problem by rebooting my system and reauthenticating to the site. I am then able to republish my template at least once.
Things I have tried:
Clearing my SSL state in Internet Explorer, reauthenticating to SharePoint in the browser
Starting InfoPath from the run prompt with the following switches: infopath /cache clearall
Rebooting (always fixes the issue - would like to avoid this)
My corporate SharePoint site sits on a different domain than my desktop. This could be an issue here, but I don't know why it would persist after reauthenticating.
This topic may fit more neatly on the SharePoint SE site, but the potential for networking related problems made me feel the need to post it to SO.
For me, I was able to resolve by closing out of IP and then bringing up Task Manager and killing a still living IP process. Opening IP and republishing. No reboot required.
Hope this helps someone.
This issue occurs because the Desktop Experience feature is not enabled on the Windows Server 2008 R2 server. Therefore, connections cannot be made from the Windows Server 2008 R2 server to the SharePoint server.
Source https://support.microsoft.com/en-us/kb/2752612
I have problem printing reports to PDF through bullzip from Navision Application Server (1) if user is not in Local Admin group (2). Only under both conditions.
In Nav code I'm doing the following: init bullzip automation object (set all parameters to suppress GUI), run report to print document to virtual bullzip printer, catch output file. Thats it. Straight as a rail.
I have two environments: Windows Server 2008 and Windows 7 (different versions of Nav, but this is changing nothing). On Windows 7 it just do nothing (but works if user is admin). On server I can see error in Event Log (translated to English)
Faulting application gui.exe, version 9.8.0.1599, time stamp 0x517126dc, faulting module USER32.dll, version 6.0.6002.18541, time stamp 0x4ec3e39f, exception code 0xc0000142, fault offset 0x0006f52f, the process ID 0x3bc, application start time 0x01ce562238369fa9.
Gui.exe is a part of bullzip.
If I run the same code from Nav Classic Client, or from the same NAS launched in command line, or under local administrator account, or if i put the NAS user in local admin group - it works just fine.
To solve this problem i need to find out one of two and how to fix it:
What is the difference between local admin and regular user that could cause application to crash in non-interactive mode (service) under regular user account.
What is the difference in running NAS as service and as command line that could cause application to crash when run as service.
What I've tried so far: extend non-interactive desktop heap, give user all local privileges that admin have in gpedit. Not works. Don't know direction for further digging.
Any alternative free pdf printers advices are welcome.
This question is still actual. Though I've managed to setup PDF printing with PDFCreator. The tough part was to let several different NAS to print simultaneously. And now the setup have a bottleneck - PDFCreator's printing queue. With bullzip automations it could be avoided.
We've had some cases where third party DLL's have crashed within NAV due to permission restrictions.
The only effective way we could narrow down the files that it was trying to access was through using Process Monitor to try narrow down what was causing permission issues.
We found a folder within System32 to do with the System's Network Profile that some DLLs use. On that note, NAS's and such should be run under a domain account.
I think re-installing the application will do that,
Just make sure you are uninstalling each bullzip and ghost script,
Now Ghost script is tricky thing, if you are installing 32 bit over 64 then you are having problem,
refer this download link download appropriate version, install it,
and then install bullzip, after downloading new version from here
this will do..
then also if any problem(if you are using application for automation, you require new com object..) refer Forum, that explains most of application interface problems..
where you need to use public class PdfSettings with namespace bioPdf.
I hope this will help ..
I am trying to save an Excel 2010 file to a Sahrepoint 2010 document library but keep getting the error:
"You can't open this location using this program. Please try a different location"
Googling this suggests enabling "Desktop Experience" on the server which I have done. All Excel services are activated.
Has anyone come across this and been able to resolve successfully? I am wondering if this is more security related but the security set-up looks fine.
Any suggestions?
Thanks
I think that there are potentially a couple of things that could solve this problem depending on your set-up.
You are right that a lot of internet advice is to enable desktop experience, but if you are not running on the server or if you have already done this then one of the suggestions below could help.
This is only for dev environments however.
If you are running on the server and trying to use your app as admin then configuring IE ESC to turn off enhanced security for Admins should help
If you are running off server and have the issue and do not want to turn off IE ESC (on the server) for users then you need to enable a mechanism to allow auto-logon, either through integrated security (i.e. you are part of the domain), accessing through an anon web-site port on your SharePoint app (set-up anon web access in SharePoint) or set up and store a WebDav link and use that as the open/save URL.
My (unconfirmed) theory is that there is some auto-login going on in the background that hinders a streamlined office integration. Most of the time, SharePoint will be set up with Kerberos (not NTLM) or be in anon mode so enabling desktop experience if running on the server will be the best first step to try.
Hope this helps.
The problem is that the full path to the file is too long.
I had this problem with a PowerPoint presentation. The full path to the file was over 275 characters. When I shortened the file name to bring the full path under 250 characters, I was able to open the file normally.
I am running my C++ servi ce on Win2008 server machine. It crashes randomaly, and i do not know why. This is happening on multiple machines in customer site.
How can i configure the system to auto generate a dump of the process?
I need a method that will require minimal installations and UI, preferably only some registry hacks.
Thanks.
[edit] waiting...
You can use Windows Error Reporting locally on a machine without having to involve Microsoft and without having to sign your code. WER can be configured to store local copies of dumps. The MSDN documentation is here:
http://msdn.microsoft.com/en-us/library/bb787181(v=vs.85).aspx
It's a simple, well thought-out system, and is only a couple of registry settings to configure.
If your customer allows then i would suggest you to install DebugDiag from Microsoft. You can configure the tool to generate dumps when your application crashes and ask them to send you those dumps. I have used this quite often and found it to be successfull. If any help required please let me know.
Sign your executable then register with Microsoft for Windows Error Reporting (the signing certificate costs but WER is free). This will then collect the crash logs when the user hits the 'Send to Microsoft' button. These logs will then sit there until you log in to retrieve them. This requires no other installations on the user's machine.