To navigate through the Ribbon, use standard browser navigation keys. To skip between groups, use Ctrl+LEFT or Ctrl+RIGHT. To jump to the first Ribbon tab use Ctrl+[. To jump to the last selected command use Ctrl+]. To activate a command, use Enter.

This saturday I did a session at Office 365 Saturday: Monitoring SharePoint usage and Performance using Application Insights​.

The session went ok, but demos weren't that exiting, since Azure Application Insights (which is still in preview) were down during my session. I knew they were doing updates on the service, so I took some screenshots.

Please find my presentation and PowerShell/JS used in demo in this zip.

Since the company I work for are working with a lot of different clients, most of my work happen in remote desktops on different client networks.

Hence I have created a dedicated VPN client machine on HyperV that I use for connecting to these networks using different VPN clients.

Since most customers have disabled that you can run VPN from a remote desktop client, you need to connect directly from a host session in HyperV rather than connecting to it remotely.

I recently upgraded that machine to Windows 8.1 Enterprise 86x, and noticed that even after upgrading my Cisco AnyConnect​ to latest release (that works with Win 8.1) my session was detected as a remote desktop and connection was rejected with the error "VPN Establishment capacity from a remote desktop is disabled. A VPN connection could not be established".

One of the new features in Windows 8.1 is the ability to copy/paste directly into the HyperV host session, which was something you could only do in Remote Desktop in earlier versions. This turned out to be the caveat: once i disable Enhanced Session from View > Enhanced Sessions and log in again, the VPN connection worked fine!

​In SharePoint 2010 accounts comes in two flavours: Managed accounts and Service accounts. This means we have to dig a bit around to get an overview over what accounts are actually used. Since some are managed account and some are not, the PowerShell commands below in some cases return the same accounts. Think of the commands as a quick shortcut to get an overview of where certain accounts are used in your farm:

First off, you can get an overview of the existing managed accounts simply by typing

Get-SPManagedAccount

This however does not tell you where an account is used, so lets dig a bit deeper.

First lets see where we should expect accounts to surface. The below list is probably not complete but drop me a comment and I will add any accounts I have missed out:

The above commands should give you an overview of where your accounts are used. There are more accounts not listed above, for example all accounts used for Secure Store, unattended service accounts for services like Visio, but most are covered above.

If I have forgotten some important accounts or if you see something blatently wrong in the above, feel free to comment :-)

It is often useful when you do SharePoint development to be able to deploy indexed and managed properties and property mappings in a repeatable way across environments.

In SharePoint 2010 we did this as part of our PowerShell provisioning, but things have changed a bit in SharePoint 2013. Not only have the managed properties changed quite a bit with the introduction of Managed Navigation, but also as a developer and architect you really need to think Cloud First if you want your deployment frameworks to work both on premises and in the cloud.

So the idea here is that you configure your SSA as you want to, with crawled properties, managed properties, mappings, query rules etc, you then import them into your "next" environment, that being either TEST, PREPROD or PROD. This especially helpful when you use TFS and Lab Management to spawn up and test your code and deployment.

The crawled properties will show up in the CategoriesAndCrawledProperties section.

NOTE: I only got the Mappings part of search configuration settings to work for SearchObjectLevel SPSite, not SSA. I will look further into this, but if anyone has an idea to why this does not work, throw me a comment!

​If you have set up a SharePoint 2013 farm, for example for your development box, chances are you have wondered where all that good RAM went, and why performance is so slow when you start to add service applications to your farm.

A check in Process Monitor reveals that a fair chunk of RAM is used by a number of processes called Noderunner.exe (Microsoft® SharePoint® Search Component). These are the components you configured when creating your Search Service Topology. If you did this in PowerShell you can decide which components should run on what server (eg. Analytics Processing or Admin component).

In beta these processes had a memory leak, and the "cure" was to limit the space used by changing noderunner.exe.config. This however is *not* supported, and not recommended, so don't do this on production environment! If your components run out of memory they will start acting very weird and/or crash. I even have managed to kill my farm beyond repair by setting the memory limit too low, so consider yourself warned!

Another option for your dev farm is to change your performance level of your search service using

Set-SPEnterpriseSearchService -PerformanceLevel Reduced

This will reduce the maximum numbers of threads to the number of available processors. Note that this will only have effect on the server instance running the crawl component.

Fair warning: If you already have created a User Profile Synchronization connection that uses UPS, this and all its mappings will be deleted at this point!

It is true that articles mention that you can "swap between" UPS and AD Import, but it comes at a price: all your mappings will be gone! If you provision and export those using PowerShell and XML (as I do) and those XML files are up to date with what ever user configuration your users have been up to, this is fine! But if not, you are out of luck! Anyone who have tried setting up mappings manually, feeling like an idiot clicking those small "up" and "down" arrows to move properties on the public profile page will know what I am talking about :-)

Now all we need to do is create a new Synchronization Connection:

You can only select Active Directory Import. Authentication provider can be Windows, Forms or Trusted Claims Provider.

At the very bottom you can select LDAP Filters in a tiny text box (almost comically small, considering how large those LDAP filters can grow really!).

<EDIT>

As Spence pointed out after me publishing this post, there is a nice little check box for filtering out disabled users.

The quirks are the same though when you use the checkbox, and for other filters as well, so the conclusion (if there are any) stands :)

</EDIT>

First try and set up your connection without filters: add domain name, user name and password (remember that the account must have Replicating Directory Changes permissions, just like with UPS, nothing changed there!), click Populate Containers and select the OU's you want to include in your synchronization.

Click OK and go back to the User Profile management page. Here you select Start Profile Synchronization and select a Full Synchronization for the initial sync.

So while that one finishes... uhh wait!??! It is already finished! WOW that was fast huh? ;-) Nothing slow about this babe comparing it to the FIM sync!

So next step is LDAP filters! What is the syntax?

It is probably no surprise to the admin guys out there that LDAP filters are no new invention. There are tons of info out there on the syntax of these bad-boys, here are a few:

A thing to point out here, that may or may not seem illogical to you, is that in LDAP filters you dont tell what items to exclude, but what to include (in contrast to when you create UPS Exclusion filters). So in order to tell the Synchronization Connection to filter out disabled users, we need to tell it to only include enabled users:

(&(objectClass=User)(!userAccountControl:1.2.840.113556.1.4.803:=2))

The thing to point out here is the "!" (or "not" if you happen to be a developer). In plain wording it say: "Give me all users who are not disabled". Hint: You can use ADSIedit.exe to check the userAccountControl setting on your AD objects.

So why use LDAP filters at all when we have UPS Exclusion filters? Well as the name kind of gives away, those babies only works on UPS, and we are not using UPS, we are using AD Import, right?

OK so lets try and set this up on our synchronization connection: just paste the above (or any other filter you may need) into the Filter in LDAP syntax for Active Directory Import field and populate the container. First thing you notice is that the filter dont seem to be applied on the tree view that is opened. This is probably per design I would venture...

After setting it up, go to your AD and list (for example with an LDAP filter ;-) disabled users in the selected UA. Also try and add some new users, both disabled and not.

Now do a sync (an incremental seems to be enough to make the filter take effect).

What happens now in my experience (on beta2 anyway), is that any disabled users already in your user profile stays in the user profile. This may and may not surprise you, but apparently that is how this importer works: since the filter is no longer including these disabled users, they are simply left alone! Trying to update these users confirms this: adding a value in a mapped property is not propegated to the user profile either.

So what happens if you disable a user that is already in your user profile, and you have the above LDAP filter applied? Well, still nothing! Same as before: since the user is not in your import its user profile is no longer updated. Eg. if you set an email on the disabled account and synchronize, changes are not moved to the user profile.

In both cases this kind of makes sense, since the user is not included any more, but the fact that it is not considered "deleted" or "removed" might surprise you administrators out there: you will have to delete already included user profiles for disabled users yourself!

So what happens when you delete a user in your AD and you are using AD Import?

Just like when running FIM users are marked for deletion in the Profile database when an incremental sync would detect that the users were gone. After a while (every hour in SP2010, but at least in SP2013 beta2 this was changed to daily) the My Site Cleanup Job would finish up removing User Profiles marked for deletion (for more info read another blog post by Spence here on Account Deletion).

So this works like with UPS. Well almost:

An unexpected gotcha: the users with disabled accounts that was initially included in the User Profiles are not deleted when the LDAP filter to only include enabled users are active on the AD Import synchronization connection! The logic behind this is the same as before: since the user is no longer a part of the import, it being deleted is ignored!

So what do we conclude? Old skool LDAP filters does work -kindof, but be aware of the above mentioned quirks!

If you use AD Import, LDAP filters are the only option! And I never thought I would have to say this, but the nerdy LDAP filter syntax actually is easier than working with UPS Exclusion filters, but that is mostly because of the really non-intuitive and quirky UI that UPS Exclusion filters have...

We had a request by a customer that external users should not be able to view My Site Public Profile pages. This proves a challenge because SharePoint links to _LAYOUTS/UserDisp.aspx?id=123 all over the site (for example in Modified By columns on list views). Out of box SharePoint have delegate controls that check if you have a My Site Host running or not, or if the user id you requested is a group or a user. Clicking on these links for users without access to My Site Host would simply give them a prompt to a site they would't have access to, so not optimal!

Instead I wanted to link them to the view that you get if you *dont* have a My Site Host: The item view in the user info list instead. As a plus that would make it possible for me to decide what info these limited access users should see using the "replicable" checkbox in Edit User Profile Properties:

There are alot of info out there on SharePoints Hidden User List, for example check my buddy Tobias Zimmergrens blog post on this topic.

So to short-wire this logic I created a new delegate control with same ControlId "Redirect ProfileRedirection" just with a lower squence (40) (shout-out to Keith Dahlby for putting me on the right track with this post).

The check could have been done in many ways, but since I knew that the users who didn't have access to My Site Host was in a specific security group in AD, I chose to use an audience for "internal" and "external" users that I was already using for other purposes.

I use the IFormDelegateControlSource interface in my delegate control as this gives me the proper hook and object (in this case the relevant users SPListItem from user information list).

The code also includes the original code that I override (Microsoft.SharePoint.ApplicationPages.UserDisplayPage) that checks if a user is a person or group. To make sure that the user info list item view is used instead of the profile, I add a Force=true parameter to the query string. This is the OOB way of enforcing this view is used no matter if a User Profile Service is running on the farm.

/// <summary> /// This class is called by a delegate control in AdditionalPageHead before the UserDisplayPage delegate control /// that takes care of redirection to My Site public profile. /// We want to short wire this redirection for users with no access to My Site Host /// </summary> public class RedirectToUserList : UserControl, IFormDelegateControlSource { public void OnFormInit(object objOfInterest) {

After creating this class, we need to include it in a feature using a delegate control (I use the Delegate Control Visual Studio item template from from CKSDev, but you can also use an Empty Element template):