I have recently upgraded my microsoft dynamics crm from 2011 to 2013, all seemed to go accordingly however whenever i try to access any of my reports custom or out of the box they refuse to load. I either get an error which says the report cannot be loaded (rsprocessingaborted) and if not this then it totally refuses to load almost as if some script is being blocked(2nd screenshot). I'm completely lost on this and any help will be greatly appreciated :-)
Try turn on trace, restart IIS and reproduce an error. Then recheck trace file to get explanation of an error.
I had the same problem when I run a CRM migration.
Just follow the steps :
http://ashwaniashwin.wordpress.com/2013/07/21/crm-2011-reporting-error-the-report-cannot-be-displayed-rsprocessingaborted/
Note that this is the same as the steps in the Microsoft KB article, https://support.microsoft.com/en-us/kb/946585, which in summary involves ensuring if SQL Server Reporting Services service is running under the Local System account to add the NT Authority\SYSTEM to Security -> Logins in SQL Server Management Studio and to add this account in the User Mapping to the MSCRM_CONFIG and Organization_MSCRM databases with roles of CRMReader, public, and db_owner.
Related
I'm trying to bring a new server, with SQL Server 2012 Data Warehouse edition installed, into production. Recently the act of deploying a new SSAS database definition using Visual Studio immediately causes the user that owns the installation on the server to become locked out of the network. Neither I nor the network administrator can figure out what is going on.
I'm perfectly willing to believe that somewhere deep within Visual Studio it has an incorrect password for that user and is making several sequential attempts to log in until the network locks the user out. But I have no idea where in Visual Studio that user/password is stored so that I can check it.
FWIW, I'm deploying things from a Visual Studio installation on my client computer using my personal account. The account that is immediately getting locked is a specially created network account to be used for installing and running the server software.
Where can I find the referenced user account? What else might be happening?
Have you tried using the SSAs import wizard instead of using VS?
I use visual studio team foundation server 2013 on windows server 2008 R2 and SQL SERVER 2014, When I want to "get latest" or "check in" files from Microsoft visual studio occurred this error:
TF53001: The database operation was canceled by an administrator.
So, One of the projects on the server is in trouble and the others do not have problems.
I had this trouble before, you should update your sql server to latest service pack version.
try this one https://download.microsoft.com/download/2/F/8/2F8F7165-BB21-4D1E-B5D8-3BD3CE73C77D/SQLServer2014SP1-KB3058865-x64-ENU.exe
We had just the same issue.
The service account had been disabled.
It seems some data was cached somewhere on client such that some collections seemed operational on the clients which are used to working with that collection. but actually for many operations it was not working (for example creating a new repository
My TFS 2013.4 server suddenly started doing this.
I eventually changed the Compatibility Level of the TFS databases to Server 2014 (120) and restarted TFS, and it worked!
Strange thing, the other Team Project Collections still worked, it was just the one we were busy on that had this issue....
on my computer I have a problem with connection to TFS 2013 using Visual Studio 2013 and 2015. This problem occurs on only one machine. Other users in the net can work without problems. In the same time I can connect to projects on Visual Studio Online. Problem happened after switching a few times between projects. Nothing was installed or changed either on my computer or on TFS Server. I've got following error: "Technical information (for administrator): The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF".
I've check this article:
https://msdn.microsoft.com/query/dev12.query?appId=Dev12IDEF1&l=EN-US&k=k(vs.tfc.connecttotfs.unabletoconnect)&rd=true
But in section: "You receive this error when you try to connect to an on-premises TFS from your client computer " I didn't found solution. I also reinstalled Visual Studio but it didn't solved my problem.
How to solve this? Is there a way to check some logs or events to find a reason? Thanks in advance for your help.
Regards Pawel
To narrow down this problem, try the following actions:
1.check whether there is something wrong with user account
a) Connect to TFS with the same user on another machine.
b) Login in tfs web access in web browser with your account
2.Clear TFS local cache http://www.ewaldhofman.nl/post/2009/07/06/Clear-the-cache-of-TFS.aspx For TFS 2013 the default path: C:\Users\XXX\AppData\Local\Microsoft\Team Foundation\5.0\Cache
I have a Visual Studio 2012 and a Microsoft Dynamics CRM 2013. I use the CRM SDK Visual Studio plugin to connect my VS to the CRM. On my machine it works, on my colleagues machine it does not work. He gets the following error message when clicking the login button:
The request for security token could not be satisfied because authentication failed
I set up all machines and my Windows client machine was added to the domain automatically. We added his machine, too (via Active Directory Users and Computers) but that did not help. We both use either default credentials or login with the domain administrator (domain\administrator) with the same results.
What do I have to configure to enable my colleague to login, too?
Detail information: Server is a Win2012 R2 Server, clients are both Win7.
Cheers,
Arne
We solved the problem. A look in the appropriate place in the event log showed that the Visual studio sends the wrong credentials when the login is performed
during startup of VS. When that is canceled, the startup completes and afterwards the connection to the CRM is made, VS sends the correct credentials
and the login works.
I hope that helps someone to save some time.
Cheers,
Arne
I've recently put Windows 7 on my development PC, and I have Visual Studio 2008 Team System Development Edition, and SQL Server Management Studio 2008, and for some reason I can't seem to step in to any SQL code for debugging in SSMS.
Before I formatted in favour of Windows 7, I was able to debug on the same two SQL servers I'm trying now with the same software, so I'm guessing it's something to do with client configurations. Regardless, I tried all the steps I could find to enable SQL remote debugging but nothing has worked.
When I attempt to debug or step into the active query window, the debugger simply runs the code without stopping at the start or any breakpoints.
If I try use Visual Studio (running as Administrator) I get the following error:
T-SQL execution ended without
debugging. You may not have sufficient
permissions to debug.
Anyone got a clue what to do here?
EDIT
I'm still having this problem. I re-installed the latest SQL Server Management Studio from MSDN's latest SQL Server 2008 download available, and patched it with SP1, but this same problem still happens. Other people in my office are able to debug code with the same version client, and same permissions (set using group permissions) so I'm at a loss as to what is causing this.
FINAL EDIT
Solved! The issue was simply a domain authentication issue. See my answer for a larger explanation.
Have you made sure that in Server Explorer (In Visual Studio), if you right click on your connection that you have "Allow SQL/CLR Debugging" and "Application Debugging" checked?
Today, I finally solved this.
I was writing an ASP.NET application that included the line:
User.IsInRole("DOMAIN\\Administrators");
And this was throwing the following exception:
The trust relationship between this
workstation and the primary domain
failed
I wasted a little time applying the KB976494 hotfix, which I soon discovered didn't work. During my developer rage I looked in my local "Administrators" account and noticed it listed almost all members by their S-ID, so figured there may have been a domain problem.
Then it came to me... I remembered I joined the domain with my personal (non-administrator) account, instead of using the domain administrator account.
These were the ultimate steps to fix this issue:
Leave your domain (and join an arbitrary workgroup, such as "WORK")
Reboot.
Join your domain with your "DOMAIN\Administrator" account
User.IsInRole() now worked, so out of curiosity I checked this problem, and it was also fixed.
This is a great Friday so far!