How To Create the UPA from Powershell

Creating the User Profile Service Application (UPA) via Powershell is a fairly straightforward process. We only have to follow these steps:

  1. Set Parameters
  2. Create the Service Application
  3. Create the Service Application Proxy and associate it to the Proxy Group
  1. Set Parameters: First of all we have to set the parameters we will use for the service application.
  • Name for your User Profile Service Application
  • $UPAName = “70331_UserProfile”
  • Application Pool: You can create a specific one or use an existing one. I recommend to use the same Application Pool for all service applications. In my case, I am assigning the existing application pool called “ServiceApplications” to the $appPool variable:
  • $AppPool = Get-SPServiceApplicationPool –Identity “ServiceApplications”
  • Database Names: UPA uses three distinct databases: Profile, Social and Profile. Try to follow the convention rule you have for your farm databases. $SocialDB = “70331_UserProfile_SocialDB”
  • $SyncDB = “70331_UserProfile_SyncDB”
  • $ProfileDB = “70331_UserProfile_ProfileDB”
  • Proxy Name: Type a name for the Proxy/connection of the UPA
  • $UPAProxy = “70331_UPA_Proxy”
  1. Create the Service Application: Use the New-SPProfileServiceApplication cmdlet for this purpose and use the recently created parameters and collect the result in the $UPA variable so as to use it later in the Proxy creation.

$UPA=New-SPProfileServiceApplication -Name $UPAName -ApplicationPool $appPool -ProfileDBName $ProfileDB -SocialDBName $SocialDB -ProfileSyncDBName $SyncDB

  1. Create the Service Application Proxy: Use the New-SPProfileServiceApplicationProxy cmdlet and the parameters configured above. Use the option DefaultProxyGroup if you want to include the proxy into the default group.

New-SPProfileServiceApplicationProxy -Name $UPAProxy -ServiceApplication $UPA –DefaultProxyGroup

  1. If you did not associate the user profile proxy to the default proxy group and you want to associate it to a custom one, do the following:

#Get the list of Proxy Groups and copy the Friendly Name of the Proxy group you need.


$proxyGroup=Get-SPServiceApplicationProxyGroup -Identity “Intranet Only”

#Get the list of proxies/connections, copy the typename of the UPA proxy and use it for assigning it to the $proxy variable

$proxy=Get-SPServiceApplicationProxy | ? {$_.TypeName -eq “User Profile Service Application Proxy”}

#Use the Add-SPServiceApplicationProxyGroupMember cmdlet to add the UPA proxy to your custom ProxyGroup

Add-SPServiceApplicationProxyGroupMember -Identity $proxygroup -Member $Proxy

That´s all, hope it helps!

Merging multiple CSV Files with Powershell

Powershell is a great tool for managing CSV files, specially with the cmdlets Export-Csv and Import-Csv. Let´s use it to merge multiples several CSV files. The process is:

  • Get the list of CSV files
  • Import the content of every CSV file into the same variable
  • Export the content of the variable to a final CSV file


First we get the list of CSV files, which are located in a folder using the Get-ChildItem cmdlet:

$csvfiles=Get-ChildItem -Path C:CSVFiles*

If there are other files with other extensions we can use wildcards like this:

$csvfiles=Get-ChildItem -Path C:CSVFiles* -Include *.csv

Or, if there are more CSV files than you are intested on you can still use wildcards to filter by title for example:

$csvfiles=Get-ChildItem -Path C:CSVFiles* -Include *<word_of_interest>*.csv


Once we got the list of CSV files to merge, we process each file importing the content of each file to a $content variable

foreach ($file in $csvfiles) {

$content += Import-Csv -Path $file;



Last step is export the content of the $content variable to a CSV file using the Export-Csv cmdlet

$content | Export-Csv -Path C:CSVFilesMerged.csv

And that’s all…

Note: this method is very simple but we need to have the same structure in the CSV files (same columns), since the declaration of columns is found in the first line of a CSV.

Hope it helps!

Performance Counters


  • A primary counter is a counter that we should check first to detect any problem.
  • If we detect a problem with primary counters then we can use secondary counters to have more info about that problem
  • Remember, it´s very important that we pay attention to values over a period not peak values.


  • The main performance counter for detecting CPU problems is Processor% Processor Time and measures the percentage of time the processor is being used. Values under 50 % is healthy, values between 50-80 % we should be worried about and values between 50-80 % “Houston we have a problem”

Processor% Processor Time is the addition of two counters: % Privileged Time and % User Time

  • Another primary performance counter is Processor(*)% Privileged Time, which measures the percentage of time the processor is being used by the Kernel, that is, the percentage of time that a thread is running in Privileged Mode. For example, when an application calls an Operating System function (disk operation, network, memory) this function runs in privileged Mode.

Values under 30 % are healthy, between 30-50% we should be worried about and values over 50% “Houston we have a problem”


  • SystemContext Switches/sec: Context switches take place when the kernel change the CPU assigned from a thread to another one. When this value is high it means that CPU is being pretty much shared, that is too many threads fighting for CPU resources. We should check this counter when % Privileged Time has high values. Recommended values are under 5000. We should start worrying with values of 2500x#CPUs. Prolonged values over 5000x#CPUs mean we have a problem.
  • Processor(*)%Interrupt Time. Interrupt Time is the time that the CPU uses for interruptions, that is, in I/O operations like network and disk access. Therefore, high values of this counter may indicate that we should analyze the disk and network access performance. Healthy values are under 10%, worrying values between 10-20% and we have a problem when this value is higher than 20 %.

SystemProcessor Queue Length: It measures the number of threads are in queue, waiting for running. Healthy values should be between 0 and 1. Values between 2 and 5 may indicate a problem and prolonged values over 5 is meaning a problem.

NLB Unicast Vs Multicast

In this post I´m trying to explain the two kinds of Operation Mode we have in a NLB configuration.

This is one of the NLB Cluster properties that we need to know very clear. We need to understand both operation modes, the differences between them and when it is recommended each of them.

The Cluster Operation Mode is a property of the NLB Cluster that specifies how the NLB Cluster is going to manage the MAC addresses of the network adapters belonging to the NLB Cluster.

How NLB Cluster works

NLB Cluster is based in MAC spoofing, that is, overwriting every outgoing packet from the NLB Cluster (from any node) with the virtual MAC and the virtual IP and receiving every incoming packet to these virtual MAC and IP.


And, regarding the MAC address of the network adapters, there are two possibilities (two operation modes): Unicast and Multicast.


  • This is the default operation mode.
  • In this mode, the virtual MAC of the cluster is set to all the network adapters and the physical MAC address of the network adapter is not used. This means that all network adapters have only one MAC address (the virtual MAC Address of the cluster) and it´s the same for all of them.
  • Therefore, in ARP, the cluster IP (virtual IP) and the IP of every network adapter correspond to the virtual MAC.
  • This configuration does not allow communication between cluster nodes through these network adapters, since they share the MAC address (there would be the same source and destination MAC in packets at layer 2).
  • At this point, analyze if service and applications that will run in the NLB nodes and determine if communication between nodes will be required. If so, you cannot use Unicast unless you use a second network adapter in each node for hosts communication purposes.


  • In this mode, the virtual MAC is added to all the network adapters, not replaced. This means that every network adapter will manage two MAC addresses (the virtual MAC and its physical MAC).
  • With this configuration, every network adapter, will use the virtual MAC only for communicate to NLB clients and the physical MAC
  • Therefore, in ARP, the virtual IP corresponds to the virtual MAC and IP of each network adapter corresponds to each physical MAC.
  • This configuration allows every network adapter to manage NLB clients traffic (virtual MAC/virtual IP) and host traffic (network adapter IP/physical MAC). So, communication between NLB nodes is possible at the same adapter.
  • At this point, you do not need specifically a second network adapter for hosts communication purposes.


  • Microsoft recommendation is to use Unicast, unless we only have one network adapter and need hosts communication, in order to avoid problems with routers.
  • In some cases, ARP implementation of some routers (mostly CISCO) does not support using multicast MAC addresses. For that reason, NLB cluster is unreachable from other subnets. The workaround of this issue usually is to add a static ARP route in the routers.
  • Regarding performance, Unicast in general can offer better performance, for Multicast is using the same network adapter for manage two kinds of traffic.
  • Virtualization…

Remember also that…

  • Regardless the operation mode, network adapters will have two IPs: the virtual IP and the specific IP of the adapter.

The virtual MAC address, this is the cluster MAC is automatically generated so we cannot specify the virtual MAC we want to use.

Disable LoopbackCheck

​It´s very common that after a hard work installing and configuring a sharepoint farm, the web applications, Kerberos, sql configurations… the first time you try to access your newly created site collection from the sharepoint server the browser constantly prompt you for credentials and finally receive a 401 error.

Don’t panic, it´s normal. In fact, is security configuration of windows systems that help prevent reflection attacks on the server. For that reason, every time you try to access to a web site from the same web server host that is mapped to the local loopback address ( you will get this error. From other client computer the Web Site will work.

There are two workarounds:

  1. Disable the loopback check. This way the server won´t check any connection to a host mapped to the loopback address. Just go to the Registry Editor and follow the next steps:
  • Locate and click the following key in the registry:


  • On the Edit menu, click Add Value, and then add the following registry value:

o   Value name: DisableStrictNameChecking

o   Data type: REG_DWORD

o   Radix: Decimal

o   Value: 1

  • locate and then click the following registry key:


  • Right-click Lsa, point to New, and then click DWORD Value.
  • Type DisableLoopbackCheck, and then press ENTER.
  • Right-click DisableLoopbackCheck, and then click Modify.
  • In the Value data box, type 1, and then click OK.
  • Quit Registry Editor, and then restart your computer.
  1. Specify in the registry the host names of the specific web sites you need to access from the same web server. Just go to the Registry editor and follow the steps:
  • Locate and click the following key in the registry:


  • On the Edit menu, click Add Value, and then add the following registry value:

o   Value name: DisableStrictNameChecking

o   Data type: REG_DWORD

o   Radix: Decimal

o   Value: 1

  • Locate and then click the following registry key:


  • Right-click MSV1_0, point to New, and then click Multi-String Value.Type BackConnectionHostNames, and then press ENTER.
  • Right-click BackConnectionHostNames, and then click Modify.
  • In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
  • Quit Registry Editor, and then restart the IISAdmin service (You don´t need to restart the server).

This  method is more recommended, since you are specifying only the host names that are allowed to be accessed from the web server.

For more info, see the official KB articles:

How to Configure Reverse Proxy

We have two web servers. One server accepts traffic from the WAN on port 80. The other accepts traffic from the WAN on port 443. Our SharePoint 2010 instance lives on the former, but we only want public traffic coming to the SharePoint server over SSL. Which, as you probably know, is port 443 by default.

What to do, what to do?

We had several options including opening up another port and allowing SSL traffic over a different port to the port 80 server. I didn’t like that idea. In the past, for various things, I’ve used the IIS URL Rewrite module for various things, so I decided to see if I could put some rules in place with that.

What I found is that URL Rewrite has a template for doing a reverse proxy. Brilliant! Fortunately for me, it’s a common enough scenario that Microsoft decided to add a rules template to version 2 of the Rewrite Module.

If you haven’t done so already, and I recommend doing it regardless of whether or not you’re doing a reverse proxy, download and install the URL Rewrite module. If you already have the IIS Manager open, you’ll need to close it and reopen it for the extension to show up.


Select your site in the Sites under your server on the left. Open the URL Rewrite extension, and click Add Rule from the Actions bar on the right-hand side. You’ll be presented with a dialog. Choose Reverse Proxy from the Inbound and Outbound Rules category.


You are likely to be presented with a dialog saying that you need Application Request Routing installed to do the reverse proxy. Not a problem, just follow the instructions and install it.


This one doesn’t have a standalone installer. At least not one that I could find. You’ll need to install it using the Microsoft Web Platform Installer. I didn’t care for that because I wanted to keep the number of components on the server to a minimum, but I didn’t have much choice.

After installing it, closing IIS Manager, and opening it again, I repeated the previous steps and this time, I was presented with a dialog related to ARR, but asking if I wanted to enable it. Of course I clicked OK.


Finally, I was presented with a simple data entry screen to configure some server and routing information. I filled it out similar to this:


If you’re doing what I’m doing and taking an HTTPS connection and forwarding it to an internal URL over HTTP, then make sure that the Enable SLL Offloading checkbox is checked. Also, if SharePoint is configured properly, as I’ll explain below, you won’t need an Outbound Rule for rewriting URLs in the response.

Now SharePoint needs to be configured properly. The internal domain that you use needs to be configured as an internet address in the Alternate Access Mappings, and the public URL needs to be the primary internet URL for the site. Let me show you what I’m talking about.

In Central Administration, go to Application Management and select Configure alternate access mappings. On the top right, there’s a drop down named Alternate Access Mapping Collection. Choose the SharePoint site that you’re putting the reverse proxy in front of.

Whatever you used as the server name in the Inbound Rules for the reverse proxy, this needs to be an internal URL for the internet zone. If it’s not already, click on Add Internal URLs and add it.


If the URL that you’re using is one of your public URLs for the SharePoint site, like mine was the public URL for the intranet zone, you’ll need to either choose a different internal URL for your inbound rule, or you’ll need to change the public URL. I changed the public URL.

The internet URL is what your HTTPS web server is using. So if the URL that you’re using on the receiving web server is, then the internet zone in the public rules for your SharePoint site should be

I believe that’s it! Because of the alternate access mapping, SharePoint 2010 will do the work for you of updating all of the URLs in the responses to use the internet URL for any requests coming in on http://sharepoint.internaldomain.internal alleviating you of the need to have an outbound rule to rewrite responses.

Configure Object Cache User Accounts (All in Powershell)

In my last post I explained all the steps to configure the object cache user accounts. It´s so simple and easy… but at the same time boring and long for such a little configuration. So… powershell to the rescue.

Here is the script to run all in one step. We need the URL of the web application, and the object cache user account to use. I thought about writing the script including all web applications but I prefer to do it one by one (just in case…)


$wa = Get-SPWebApplication -Identity http://intranet.demos.local

$superUser = “i:0#.w|demosMSSCacheSUser”

$superReader = “i:0#.w|demosMSSCacheSReader”


$fullPolicy = $wa.Policies.Add($superUser, $superUser)


$readPolicy = $wa.Policies.Add($superReader, $superReader)


$wa.Properties[“portalsuperuseraccount”] = $superUser;

$wa.Properties[“portalsuperreaderaccount”] = $superReader;


Note: The script is assuming we are using Claims Mode authentication for the web app. If this is not your case, change the format of the user account for “domainuser”.

Hope it helps!

Configure Object Cache User Accounts

STEP 1: Create the user accounts in Active Directory

Super Reader Account: domainSuperReader

Super User Account: domainSuperUser

STEP 2: Set Permissions in Central Administration

  1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group on the computer that is running the SharePoint Central Administration website.
  2. On the Central Administration website, in the Application Managementsection, click Manage web applications.
  3. Click the name of the web application that you want to configure.
  4. On the Web Applicationstab, in the Policy group, click User Policy.
  5. In the Policy for Web Application window, click Add Users.
  6. From the Zoneslist, select All zones, and then click Next.
  7. In the Usersbox, type the user name for the Portal Super User account.
  8. Click the Check Namesicon to ensure that the account name can be resolved by the authentication providers on the application server.
  9. In the Choose Permissionssection, check the Full Control – Has full control
  10. Click Finish.
  11. Repeat Steps 5 through 8 for the Portal Super Reader account.
  12. In the Choose Permissionssection, check the Full Read – Has full read-only access
  13. Click Finish.
  14. Make note of how the names for the Object Cache Super Reader and Object Cache Super User accounts are displayed in the User Name The displayed strings will be different depending on whether you are using claims authentication for the web application.

STEP 3: Set the SuperReader and SuperUser account in the Web Application (Powershell)

Copy and paste the following text into a Powershell window

  • $wa = Get-SPWebApplication -Identity “<WebApplication>
  • $wa.Properties[“portalsuperuseraccount”] = “<SuperUser>
  • $wa.Properties[“portalsuperreaderaccount”] = “<SuperReader>
  • $wa.Update()


<WebApplication> is the URL of the Web Application

<SuperUser> is the Super User account in the format domainuser

<SuperReader> is the Super User account in the format domainuser

Be careful if your web application is in Claims Mode Authentication, because you must use the format i:0#.w|domainuser

Hope it helps!

Configure HTTPS on HTTP

Step 1: Create Self Signed Certificate on IIS 8

Open IIS Manager and then go to Server name and choose IIS Section “Server Certificates


Click on Create Self-Signed Certificate… on Actions pane

Specify a name like “SharePointSelfSignedCert” and click Ok


Double click on this created Certificate and go to details Tab and click copy to File…


Click Next (Welcome…),

Select No, do not export the private key and click Next ,

Select DER encoded binary and click Next,

Specify the location for the certificate and Click Next and then finish (Imported).

Step 2: Import Self Signed Certificate to SharePoint Certificate store

Open Manage Compute Certificate on Windows Server 2012 and go to SharePoint node and then right click All tasks >> import

Click Next and then specify the location of exported certificate in previous step and then Click Next,

Make sure Certificate store is SharePoint and Click Next and then finish (Exported)


Step 3: Add Self Signed Certificate to trust management in Central Administration

Go to Central Administration >> Security >> Manage Trust (to inform SharePoint to trust this certificate also).

And Click New

And a name and specify the location for the certificate and Click Ok.


Step 4: Configure IIS Binding

Go to IIS Manager and choose your web application and then click on Binding in Actions pane


Click Add..

Type: Https

SSL Certificate: SharePointSlefSignedCert (which created previously).


Click Ok.

Step 5: Configure AAM

Go Central Administration >> Alternate Access Mapping and Choose your web application

And click on Edit Public URLs and then add HTTPS URL


And Click Save.

Now try to brows your site with HTTPS URL




Issue #1: Mixed HTTP and HTTPS Content

If you login with HTTPS URL and then redirect the user to HTTP , the browser will ask the user again to login with HTTP URL.


Go To Central Administration

Open Alternate Access Mapping (AAM)

Select your will application from the dropdown menu on top right

Click on Edit Public URLs and remove HTTPS URL

Click on Add Internal URLs and add HTTPS URL and select the same zone as HTTP URL