Donnerstag, 3. Juli 2014

SharePoint ThreadAbortException

Problem: If you are doing a SPSite.OpenWeb() (or maybe its done for you, when you request the profile service) and you do not have the permissions to the site there is an UnauthorizedAccessException being thrown. But if you are trying to catch it, immediately after the catch an ThreadAboardException is thrown and you code does not continue. That is because of access denied exceptions inside page requests are explicitly handled by the platform. For example, when Forms-based authentication is used, anonymous users are redirected to the login page. If the user is already authenticated, he may be redirected to an error message page such as _layouts/AccessDenied.aspx.
When you are developing web parts that behavior is okay but running such code in a timer job or WCF webservice is problematic.

Solution: You should turn off that behaviour by setting the following flag:

bool originalCatchValue = SPSecurity.CatchAccessDeniedException;
SPSecurity.CatchAccessDeniedException = false;

try
{
   // your code

}
finally
{
   SPSecurity.CatchAccessDeniedException = originalCatchValue;
}


Within the try statement you are able to catch the UnauthorizedAccessException as usual.


2nd Problem: Another reason you get a ThreadAbortException could be that your request could not be validated by SharePoint. This could be the case if you are developing a WCF webservice within SharePoint context. In the exception stacktrace you should see  Microsoft.SharePoint.SPWeb.ValidateFormDigest()

Solution:
In this case SPContext.Current is not null, Sharepoint tries to verify requests using security validation digest provided by FormDigest Class. According to msdn:
"To make posts from a Web application that modify the contents of the database, you must include the FormDigest control in the form making the post. The FormDigest control generates a security validation, or message digest, to help prevent the type of attack whereby a user is tricked into posting data to the server without knowing it. The security validation is specific to a user, site, and time period and expires after a configurable amount of time. When the user requests a page, the server returns the page with security validation inserted. When the user then submits the form, the server verifies that the security validation has not changed".
In WCF service you don't have security digest. To avoid this check try to set HttpContext.Current to null temporary when you call siteCollection.Add() method:

var ctx = HttpContext.Current;
try
{
    HttpContext.Current = null;
    // your code
}
finally
{
    HttpContext.Current = ctx;
}

Donnerstag, 19. Juni 2014

UserProfile Sync problem:Could not connect to http://(server):5725/ResourceManagementService/MEX

Problem: You are trying to sync user profiles from active Directory and get an error:

Could not connect to :5725/ResourceManagementService/MEX. TCP error code 10061: No connection could be made because the target machine actively refused it


Solution: Verify that windows service "Forefront Identity Manager Service" and "Forefront Identity Manager Synchronization Service" are started. If not, please start them and then check the effect.

Mittwoch, 16. April 2014

Office 2013 breaks your SharePoint 2010

Problem:
After installing Office 2013 on your SharePoint 2010 box you experience the following, when trying to upload an InfoPath form:

There are some policy files that reference the wrong assemblies. The following post got me to the right solution: http://smindreau.wordpress.com/2012/12/04/office-preview-2013-breaks-your-sharepoint-2010-enterprise-notably-infopath/

Solution:
Basically you must:
1. Entering the path C:\Windows\Assembly\GAC_MSIL in the Start/Run
2. Delete the following three folders:
 Policy.14.0.Microsoft.Office.InfoPath
 Policy.14.0.Microsoft.Office.InfoPath.Client.Internal.Host
 Policy.14.0.Microsoft.Office.InfoPath.FormControl
3. Run an IISRESET from a command prompt.

Montag, 3. Februar 2014

Can't connect to my Windows Azure VM!

Problem: Tried to RDP one of my VM’s and I can’t connect. Possible firewall port issue?

Explanation:  It’s important to remember that the port that you’re using for RDP is not the traditional 3389.
“It’s not? How does that work?”
Let’s step back for a second and consider what you see when you first create a virtual machine in Windows Azure and you get to the screen where “endpoints” are defined. By default, it looks something like this…
Virtual Machine Configuration
…Notice that, even though the operating system is going to have Remote Desktop enabled and will be listening on the traditional port 3389, the external “public port” value that will be redirected to the “private port” 3389 is going to be something different.
“Why?”
Security. We take the extra precaution of randomizing this port so that tools that are scanning for open 3389 ports out there won’t find those machines and then start attempting to log in.
---
Let’s go one step further here and propose a couple of solutions to this, in case you also run into this problem.
Solution #1: Open up the proper outbound firewall ports
In the properties of your virtual machine, you can find what “public port” was assigned to the VM under the endpoints tab…
VM Properties - Endpoints tab
So this web server of mine is answering to my RDP requests via my ability to connect to it’s service URL and port 56537. Since I am not restricting outbound ports, this isn’t a problem for me. But knowing what this port is can help you understand what needs to be opened for a particular machine.
“Is there a range of ports that I need to have open outbound?”
The port that will be assigned automatically is going to come from the “ephemeral port range” for dynamic or private ports (as defined by the Internet Assigned Numbers Authority) of 49152 to 65535. So if you simply enable outbound connections through that range, the defaults should work well for you.
Solution #2: Modify the VM End Points
You’ll note on the above picture that there is an “edit” option. You have the ability to edit and assign whatever port you want for the public port value. For example, I could do this…
image
…and just use port 3389 directly. Of course, this would defeat the purpose for using a random, non-standard port for remote desktop connections. But it could be done.
Solution #3: Use some other remote desktop-esque tool over some other port.
The server you’re running as a VM in Windows Azure is your machine, so there’s no reason you couldn’t install some other tool of choice for doing management or connecting to a remote desktop type of connection. Understand the application, what port needs to be enabled on the firewall of the server, and then add that port as an endpoint; either directly mapped with the same public/private port or using some other public port. It is entirely configurable and flexible. And as long as you’ve enabled the public port value as a port you’re allowing outbound from your workplace, you’re golden.
Solution #4: Use a Remote Desktop Gateway
How about instead of connecting to machines directly, you do something more secured, manageable, and along the same lines of what you would consider for allowing secured access into your own datacenter remote desktop session hosts: Configure one server as the gateway for access to the others. In this way you have the added benefits of just one open port; and that port is SSL (443). You’re very likely already allowing out port 443 for anyone doing secured browsing (HTTPS://…), so the firewall won’t get in the way.