Why Choose Us?

We strive to offer the best solution for your business and impartial advice at an honest price. We are constantly investigating new technologies and recommend them when they make sense.

We love what we do, some might say a bit too much, and we bring enthusiasm and commitment to every project we work on. Put simply, if you want a partner who cares about your business choose Pena Informatika.

We Listen

We listen, we discuss, we advise. Sounds obvious but we listen to your ideas, plans and objectives for your business. We then select the best solution to fit.

Creative & Technical

Whether it’s website or graphic design, system development or custom programming we like to keep everything under one roof to make it easier for our customers.

Experience

As a company we have been trading since 2012. We love discussing and planning new projects and have years of knowledge and experience that we bring to the table.

Passionate

We love nothing more that working on a great project with a fantastic client. We care about our clients and can often be found working out of hours to get everything ‘just right’!
Source: Why Choose Us?

Securing a SharePoint Site with SSL

Google has announced that they are starting to give more weight in search result for sites protected with SSL. If you are publishing your SharePoint sites over the internet, applying SSL should become a priority now. However, security (encryption over SSL) should be considered important whether SharePoint sites are on the internet or intranet.

Securing a SharePoint site with SSL is no different than securing other websites hosted on IIS. What we need is a valid server certificate. For development or testing environment, it is OK to use self-signed certificate, or certificates generated by local Active Directory Certificate Authority. Otherwise, we have to enroll for a certificate from external certificate authority (CA) such as Comodo SSL and Go Daddy SSL.

Signing Certificate Request with Private Key

When we create a certificate enrollment to external CA, don’t forget to sign it with a private key. We already wrote an article about this here: Signing Certificate Request with Private Key. If we forget to sign our certificate request with a private key, we won’t be able to use the server certificate in IIS for securing a website.

Install Certificate on IIS

When the certificate is ready, there should be two certificate files sent by CA to you. Each CA has different instruction on how to install those files. We enrolled the certificate from Go Daddy, so we followed their KB on how to install certificate to IIS 8 here: Installing an SSL Certificate in Microsoft IIS 8.

Create Alternate Access Mapping for Secured Site

When we are done with installation of server certificate on IIS, we should configure SharePoint to use it. Our SharePoint previously uses port 80, so to be able to use SSL (port 443), we have to create an alternate access mapping from SharePoint Central Administration:

Note: don’t forget to add an entry in DNS if you use FQDN for the new alternate access mapping URL.

Redirect HTTP Access to HTTPS

If you plan to allow only HTTPS connection, then you have to redirect all HTTP access to HTTPS. You can do this from IIS Redirection feature:

Source: Securing a SharePoint Site with SSL

Adding Slider to a SharePoint Using Content by Query Web Part (CQWP)

Modern web site usually comes with slider. SharePoint doesn’t have slider feature by default, but SharePoint is a modern web site too. So, SharePoint should be able to display slider. Yes it can, and it’s easy. We don’t have to create slider from scratch in SharePoint. It is available as separate product that can be added to SharePoint. Also if you use SharePoint 2013, you can find a lot of slider apps.

Most slider is a JavaScript + CSS library. It works with any plain HTML pages in a web browser. So, it doesn’t care with server back-end technology underlying a web page. Whether we use ASP.NET, PHP, or SharePoint, or others; many sliders should work just fine. Slider apps in SharePoint 2013 add extra feature that makes us easier to work with slider on SharePoint. But, without apps, working with slider is not difficult. In this article, we want to show you an example.

There are so many slider library available on the internet. Let us mention some of them: Revolution Slider, LayerSlider, FlexSlider, Nivo Slider, and so on. We will use LayerSlider in this post. This choice is made because we have a license of it and we already used it in one of our projects. Unfortunately it is not free: LayerSlider Responsive jQuery Slider Plugin. If you want to try a free slider, you can download FlexSlider.

Now, it’s time to go down to details. We need to use SharePoint Designer for this purpose. We use 2010 version because it will be deployed to SharePoint 2010. But you can follow similar procedure for SharePoint 2013. Here is the step by step of adding Layer Slider to SharePoint:

Step 1 – Upload Layer Slider to SharePoint

After extracting LayerSlider-5.1.0.zip (we use version 5.1.0) you should see several folders. Upload layerslider folder to a library in the SharePoint site where the slider will be added. We prefer to upload it to SiteAssets library. Note: you can use drag and drop folder between your local folder to your SharePoint davwwwroot folder. For example, our site is http://pena-dev:8003, we can access it from Windows Explorer by typing the following address: \\pena-dev@8003\davwwwroot\SiteAssets.

Step 2 – Create and Configure a CQWP Web Part in a SharePoint Page

Our scenario is to use CQWP web part as the source HTML of our slider. The CQWP web part can display images from a Picture Library. This approach eliminates the need to create custom web part. We already wrote several articles about this here:

• Playing Around with Content by Query Web Part (CQWP)
• Using Your Own XSLT in Content by Query Web Part (CQWP)
• Changing CQWP HTML Output Structure

Note that we have to change the HTML structure of CQWP output. By default it uses <ul> and <li> tag. We have to change it to use <div> tag. We can use existing XSL templates on SliderItemStyle.xsl (this is our custom XSLT formatter which was copied from ItemStyle.xsl), but in order to give more freedom on changing tags, we copied existing ClickableImage template, paste it and rename it to SliderImages:

Don’t forget to choose this new SliderImages template in CQWP web part properties:

Our CQWP should construct the HTML output according to the requirement of LayerSlider. From its simple example demo page, the HTML structure of the slider should resemble as the following code snippet:

<div class="layerslider">
  <!-- slide 1 -->
  <div class="ls-slide">
    <!-- background image -->
    <img class="ls-l" src="" />
  </div>

  <!-- slide 2 -->
  <div class="ls-slide">
    <!-- background image -->
    <img class="ls-l" src="" />
  </div>
</div>

Using techniques we already described in Changing CQWP HTML Output Structure, it should be easy to change the output of our CQWP to meet the requirement of LayerSlider.

Step 3 – Hook the Slider

Now it’s time to hook the slider into the page. We have to add references to all JavaScript and CSS files of the slider. We can do it from a single page where we want to put the slider. Or, we can put it in master page if it is required to be accessible from any pages within the site. In this article, we use the single page approach. So, in our home.aspx, we add the following code snippet:

<style type="text/css">
  .layerslider 
	width: 720px !important;
	height: 364px !important;
  
</style>

<!-- LayerSlider stylesheet -->
<link rel="stylesheet" href="../SiteAssets/layerslider/css/layerslider.css" type="text/css">

<!-- External libraries: jQuery & GreenSock -->
<script src="../SiteAssets/layerslider/js/jquery.js" type="text/javascript"></script>
<script src="../SiteAssets/layerslider/js/greensock.js" type="text/javascript"></script>

<!-- LayerSlider script files -->
<script src="../SiteAssets/layerslider/js/layerslider.transitions.js" type="text/javascript"></script>
<script src="../SiteAssets/layerslider/js/layerslider.kreaturamedia.jquery.js" type="text/javascript"></script>
	
<script type="text/javascript">
	jQuery("document").ready(function() 
		jQuery(".layerslider").layerSlider(
			pauseOnHover: false,
			skinsPath: '../SiteAssets/layerslider/skins/'
		);
	);
</script>

We use fixed-width and fixed-height for our slider, so we put inline CSS attributes for this purpose. Then we add references to all CSS and JavaScript files required by LayerSlider that we already stored in SiteAssets library.

Then, JavaScript code is called on document ready event to convert our .layerslider div into slider. Now, we should be able to see our slider inside a SharePoint CQWP:

LayerSlider has many features and options that can enrich your SharePoint pages. What we’ve shown so far is the basic or simplest LayerSlider on a page. Our emphasize is on how to use LayerSlider with SharePoint. You can experience with those bells and whistles of LayerSlider to make your SharePoint pages more interactive and interesting.

Source: Adding Slider to a SharePoint Using Content by Query Web Part (CQWP)

Changing CQWP HTML Output Structure

This post is still about CQWP, continuing our previous posts: Playing Around with Content by Query Web Part (CQWP) and Using Your Own XSLT in Content by Query Web Part (CQWP). Based on the knowledge we obtained from those previous posts, now we should be ready to make some changes in the output structure of CQWP: changing HTML tag UL and LI to DIV and DIV respectively.

By default, CQWP constructs HTML output as UL and LI tags. If we view the source or use Developers Tool to examine HTML tags from CQWP, the we can see the following construct:

<ul class="dfwp-column dfwp-list">
  <li class="dfwp-item"> .. </li>
  <li class="dfwp-item"> .. </li>
  <li class="dfwp-item"> .. </li>
  ..
</ul>

Our objective is to change it to the following HTML construct:

<div class="container">
  <div class="item"> .. </div>
  <div class="item"> .. </div>
  <div class="item"> .. </div>
  ..
</div>

And why would we do that? Well, the answer may vary, but in our case, we are preparing our CQWP to be used by a slider JavaScript library. And the slider requires using DIV instead of UL and LI.

In our previous post, we already explained how to use our own XSL formatter to output custom HTML. So, to achieve our objective changing UL and LI to DIV, we have to find where the occurrence of those tags in our XSLT file and change it there.

Open SliderContentQueryMain.xsl (this is our custom XSLT formatter which was copied from ContentQueryMain.xsl) in a text editor (note that you should check-out the file first before you can edit it), and go to line 84. You should see the following line of codes:

  <xsl:variable name="BeginColumn1" select="string('<ul class="dfwp-column dfwp-list" style="width:')" />
  <xsl:variable name="BeginColumn2" select="string('%" >')" />
  <xsl:variable name="BeginColumn" select="concat($BeginColumn1, $cbq_columnwidth, $BeginColumn2)" />
  <xsl:variable name="EndColumn" select="string('</ul>')" />

Change it to the following construct:

  <xsl:variable name="BeginColumn1" select="string('<div class="container" style="width:')" />
  <xsl:variable name="BeginColumn2" select="string('%" >')" />
  <xsl:variable name="BeginColumn" select="concat($BeginColumn1, $cbq_columnwidth, $BeginColumn2)" />
  <xsl:variable name="EndColumn" select="string('</div>')" />

Go to line 35, you should see the following line of codes:

  <xsl:variable name="BeginListItem" select="string('<li class="dfwp-item">')" />
  <xsl:variable name="EndListItem" select="string('</li>')" />

Change it to the following construct:

  <xsl:variable name="BeginListItem" select="string('<div class="item">')" />
  <xsl:variable name="EndListItem" select="string('</div>')" />

Check-in the file, and refresh our web part. Now, if we see the source of our CQWP web part, UL and LI tags have been replaced by DIV tags.

Source: Changing CQWP HTML Output Structure

Using Your Own XSLT in Content by Query Web Part (CQWP)

To change the HTML output of a CQWP web part, we have to edit out of the box XSLT template provided by SharePoint. We already wrote an article on how to do this here: Playing Around with Content by Query Web Part (CQWP). But, OOTB XSLT formatter is shared to all CQWP web parts in the same site. If you are sure that you will only have one CQWP in your SharePoint site, it’s OK to go with this direct edit approach. Otherwise, let’s try a better solution: use custom XSLT formatter for each CQWP web part.

This solution doesn’t require custom coding with Visual Studio. We need only SharePoint Designer, or it’s also doable with any text editor. We’ll break down this solution on a step-by-step below:

Step 1 – Duplicate OOTB XSLT Files

If we open OOTB XSLT formatter files in a text editor, we should come to conclusion immediately that they are all complex ones. So, don’t try to understand them entirely. Just, use them as the starting point. For our purpose in this article, we copied two of them: ContentQueryMain.xsl and ItemStyle.xsl. We paste them in the same directory and, then rename them to SliderContentQueryMain.xsl and SliderItemStyle.xsl respectively.

Step 2 – Export CQWP Web Part to a File

We can find Export menu item from the same menu where Edit Web Part menu item is located. Use this menu item to export our CQWP web part to a file. We named the file SliderCQWP.webpart.

Step 3 – Edit SliderCQWP.webpart

Use any text editor to edit SliderCQWP.webpart, and change the following two lines:

The first one is to change ItemXslLink property, point it to the SliderItemStyle.xsl location:

<property name="ItemXslLink" type="string">/Style Library/XSL Style Sheets/SliderItemStyle.xsl</property>

And the second one is to change the MainXslLink property, point it to the SliderContentQueryMain.xsl location:

<property name="MainXslLink" type="string">/Style Library/XSL Style Sheets/SliderContentQueryMain.xsl</property>

Step 4 – Upload SliderCQWP.webpart to Web Part Gallery

Open Web Part Gallery from http://<server-name>/_catalogs/wp/Forms/AllItems.aspx. Upload SliderCQWP.webpart, and rename its title to Slider Content Query.

Step 5 – Add “Slider Content Query” to Home Page

Now we should be able to use Slider Content Query web part to the home page. When adding a web part, choose Miscellaneous category, our Slider Content Query web part should be listed there.

Test

To test it, just edit the SliderItemStyle.xsl by adding some visual text that will be rendered in the web part. We can put any words here since its purpose is only for testing. For example, we added SLIDER IMG words after <img> tag:

Refresh the page, we should see the words SLIDER IMG rendered after each image in “Slider Content Query” web part. This is a sign that the web part is indeed using SliderItemStyle.xsl.

Source: Using Your Own XSLT in Content by Query Web Part (CQWP)

Playing Around with Content by Query Web Part (CQWP)

One of our favorite features in SharePoint is Content by Query Web Part, or CQWP. It is available in publishing sites or any site that activates publishing feature. In this post we will play around with CQWP to understand a little bit about how to use it, and modify its appearance.

We can use CQWP as is, add it to any SharePoint page and configure its properties. For example, we use CQWP to display images that we’ve already uploaded into Picture Library before.

Using out of the box CQWP web part, we just need to specify the source library (in this case Pictures):

Then, we need to adjust its presentation. We use Default for Group style, and Image on Left for Item style. We also use default fields to display on the CQWP:

If we view the source of CQWP web part using Firebug in Mozilla Firefox, we can see that it consists of HTML tag <ul> and <li>.

From HTML source, we can identify the CSS class of each HTML elements rendering the CQWP web part. If we want to change the appearance of CQWP content, we can add several CSS definition inside the page containing the CQWP web part. For example, to achieve the following appearance:

We add the following CSS definition on Home.aspx (the containing page):

<style type="text/css">
  ul.dfwp-list 
	margin: 0;
	padding: 0;	
  
  li.dfwp-item 
	display: inline;
  
  li.dfwp-item div.item 
	display: inline-block;
	width: 200px;
  
  li.dfwp-item div.item div.link-item 
	display: inline-block;
	width: 160px;
	text-align: center;
  
</style>

It’s easy, isn’t? But how can we entirely change the HTML structure of CQWP content? for example if we want to change the <div> tag with <span> tag. It’s also easy. The template that renders CQWP web part is located inside the site containing the web part. What we need is SharePoint Designer and a little knowledge about XSLT.

Open the site using SharePoint Designer, then on Navigation Pane, expand All Files node. Navigate to Style Library > XSL Style Sheets. We should see several XSLT files there. Open ItemSyle.xsl in editor window. Here we can see several XSL templates to render various Style that we can choose when configuring CQWP web part. We use Image on left style that corresponds to Default XSL template. Find the Default template, and we should see various elements constructing the HTML result of CQWP web part.

In the following image, we change HTML tag that corresponds to an item from <div> to <span>:

As a result of changing the <div> tag to <span> tag, the HTML output of CQWP web part is also changed:

So, we already saw that we can do pretty much anything with CQWP in terms of appearance. We can edit its appearance by overriding or adding its CSS, or we can change its HTML structure entirely by editing its XSL templates.
Source: Playing Around with Content by Query Web Part (CQWP)

Dealing with Web Proxy on WFE When Configuring Apps

Sometimes our client’s network has some policy restrictions. One of common restrictions is the enforcement to use explicit proxy in web browsers. It should be easy to deal when we use regular browsers to connect to the internet, we just need to enter proxy server name manually into the browser’s Settings window. But, when configuring Apps in SharePoint 2013, this could give us a little head ache.

SharePoint 2013 WFE needs to connect to SharePoint Apps Store (internet) to retrieve list of applications in Central Administration. However, it does not use the same connection settings as the locally installed browsers. So, whatever proxy settings we entered into the browser, it won’t affect internet connection initiated from WFE. SharePoint WFE will perform direct connection to SharePoint Store.

If this happens, our browser will display the following error message: Sorry, we can’t seem to connect to the SharePoint Store. Try again in a bit.

Solution

Fortunately there is a setting that we have to add manually into the web.config to give WFE information about the web proxy it should use when connecting to SharePoint Store. Find system.net section in the web.config, and change it to include proxyAddress attribute. For example:

<system.net>
    <defaultProxy useDefaultCredentials="false">
       <proxy usesystemdefault="True" proxyaddress="http://192.168.1.100:8080" 
         bypassonlocal="True" />
    </defaultProxy>
</system.net>

We have to enter proxyAddress value in URI form, i.e.: <protocal>://<proxy-server-name>:<port> (port can be omitted if we use standard port 80). And remember that we have to add this setting to all web applications including Central Administration.

Now refresh Apps list in Central Administration, you should see all available apps from SharePoint Store.

Source: Dealing with Web Proxy on WFE When Configuring Apps

Simple Visual Studio Workflow with Initiation Form

Creating Visual Studio Workflow in SharePoint 2010 is easy. So, don’t make the word Visual Studio scares you. It’s a little bit more difficult than SharePoint Designer workflow, but, trust us, this is not a rocket science. At certain point SharePoint Designer can no longer serve you. At that point and beyond, Visual Studio can be your life saver.

So, in this post we would like to show a very simple SharePoint 2010 Visual Studio Sequential workflow with initiation form. Eh, what is initiation form? It’s an ASP.NET form that is shown when we start the workflow manually. Initiation form gives us a chance to input data to workflow before the workflow is started for a particular item.

The Objective (End Result)

We would like to create a very simple Visual Studio 2010 workflow. This workflow will be associated with a Shared Documents library. When the workflow is started, the following initiation form is displayed:

The “workflow” itself is very simple, there is no process in the workflow that we will build. We’ll keep it very simple at this point. The “workflow” only logs anything we input in the initiation form into the Workflow History list. Here it is.

Step by Step

Here is a little details about how-to create a simple Visual Studio workflow with initiation form. We use Visual Studio 2010 and we use SharePoint 2010. Dare to make the same experiment with Visual Studio 2012/2013 and SharePoint 2013? You are welcome to put a comment in this post.

• Create a Visual Studio project using Empty SharePoint Project template.

  

• Add a Sequential Workflow project item. Name it SeqWorkflow.

  

• Right click on the SeqWorkflow project item, choose Add New Item. Choose Workflow Initiation Form, name it WorkflowInit.aspx.

  

• Inside PlaceHolderMain content area, construct the the form using existing ASP.NET controls on the toolbox. Here is an example:

  <asp:Content ID="Main" ContentPlaceHolderID="PlaceHolderMain" runat="server">
      <div style="margin: 20px">
          Title: <asp:TextBox ID="TitleText" runat="server"></asp:TextBox> <br />
          <br /> 
          <asp:Button ID="StartWorkflow" runat="server" OnClick="StartWorkflow_Click" Text="Start Workflow" />
                
          <asp:Button ID="Cancel" runat="server" OnClick="Cancel_Click" Text="Cancel" />
      </div>
  </asp:Content>
  

• Open WorkflowInit.aspx.cs, change GetInitiationData() method to return the value of Title TextBox in the form:

  // This method is called when the user clicks the button to start the workflow.
  private string GetInitiationData()
  
      return this.TitleText.Text;
  
  

• Now double-click SeqWorkflow.cs to open workflow design window. Drag LogToHistoryListActivity from Toolbox to workflow design area, below onWorkflowActivated1 activity.

  

• Implement the MethodInvoking event of logToHistoryList activity, use the following code:

  private void logToHistoryList_MethodInvoking(object sender, EventArgs e)
  
      logToHistoryList.HistoryOutcome = this.workflowProperties.InitiationData;
  
  

• We’re done. Build and deploy the farm solution, then try.

Source code: Simple visual studio workflow with initiation form source.
Source: Simple Visual Studio Workflow with Initiation Form

Using DevExpress ASP.NET Controls in SharePoint

Sometimes we get questions from our developer’s community asking about DevExpress ASP.NET Controls in SharePoint. The common question is: Can we use DevExpress ASP.NET Controls in SharePoint? The answer is yes we can. If we can use it, then how? In this post we will answer that ‘how’ question.

First thing we have to concern about the version of DevExpress and the version of SharePoint we use. Different SharePoint version requires different DevExpress ASP.NET Controls version. In this post we want to limit the scope of SharePoint versions: 2013 and 2010 (widely used at the time of writing this post).

We also have to know DevExpress ASP.NET Controls version cycle. DevExpress releases one major version each year, two minor versions for each major version, and several revisions (variable) for each minor version. For example in 2013, they rolled-out DevExpress ASP.NET Controls version 13.1.4 on June 6th, 2013. Major version is 13, minor version is 1, and revision number is 4. As you can see the first public revision number does not necessarily started from 1. Then they launched version 13.2.5 on Dec 4th, 2013. The pattern seems obvious here, the first minor version is launched on June and the second one is launched on December.

As the time of writing, the most recent DevExpress ASP.NET Controls version is 14.1.5 (Jul 17th, 2014), but we haven’t touched version 14 yet. In this post, we also limit our scope to DevExpress ASP.NET Controls major version 12 and 13 only. In other words, we may mention major version 11 or lower, but we actually haven’t tested them.

Now we will explain version matching between SharePoint version and DevExpress ASP.NET Controls version. SharePoint 2013 will work with DevExpress version 13. This is because SharePoint 2013 and DevExpress version 13 has the same .NET Framework as target of compilation: .NET Framework 4.5. On the other hand, SharePoint 2010 will work with DevExpress version 12. This is because both platform target the same .NET Framework 3.5.

So if your DevExpress version is lower than 12, you should check the version of .NET Framework as its target compilation. If it targets .NET Framework 3.5 it should work with SharePoint 2010. Also, DevExpress 14 should work on SharePoint 2013. We haven’t verified it yet because we haven’t use it for existing project. Surely we will update this post when we already apply DevExpress 14 in our future projects.

Now we will explain how we can use DevExpress ASP.NET Controls in SharePoint

Using DevExpress ASP.NET Controls in Development Environment

In Development environment, we just need to install DevExpress from its installer package. We can install it on a developer’s machine, or on web server. Launch the installer, and follow installation wizard until finish.

In Windows Explorer, open C:\Program Files (x86)\DevExpress 13.2\Components\Tools\SharePoint (note: you should replace 13.2 with your own DevExpress version). You can run ASPxSharePointRegister.exe or register its farm solutions (DevExpressSharepoint2013_GAC.wsp or DevExpressSharepoint2013_GAC.wsp) manually using PowerShell. There is also some batch files (*.cmd) to make us easier registering the farm solutions to SharePoint. Note that when installing DevExpress from its installer package we enter its registration license if we already bought one.

Then we can use DevExpress ASP.NET Controls in our SharePoint 2013 Visual Web Part project from Visual Studio 2012/2013.

Using DevExpress ASP.NET Controls in Production Environment

In Production environment, we shouldn’t install DevExpress from its installer package. We just need to copy SharePoint folder from C:\Program Files (x86)\DevExpress 13.2\Components\Tools\ in Development environment to any folder in production web server. Then run ASPxSharePointRegister.exe or register its farm solutions. Note that we don’t have to enter license information in Production environment. License information is verified only in Development environment.

Compilation and build should be performed on the Development environment where we entered our license. Assembly output from this compilation process already has license information embedded. So, when the assembly is deployed to Production environment, it won’t need to enter license information again.
Source: Using DevExpress ASP.NET Controls in SharePoint

SharePoint 2013 People Search Result Empty

If you just configured SharePoint 2013, you might stumble into common problem in Search feature: people search result is empty. We have configured several SharePoint 2013 farms for our clients and for our own Development farms, and we consistently faced this common behavior. So, today we decide to document what we did to make SharePoint displaying search result in People Search.

Check User Profile Service Application

People Search takes data from User Profile Service Application. So, the first thing you should check is User Profile Service and User Profile Synchronization Service. Make sure both services are up and running, and also make sure user data is successfully synchronized to SharePoint. You can check this from SharePoint Central Administration.

Check User Policy for Search Crawling/Content Access Account

Search Crawling account and Search Content Access account should have Read Only permissions in My Sites web application user’s policy setting. Usually this configuration has been performed automatically by SharePoint. Nevertheless, we should check whether this condition is met. If not, add it manually.

Grant “Retrieve People Data for Search Crawlers” Permission

Check whether we already grant Retrieve People Data for Search Crawlers permission to Search Content Access account. To check this, go to Central Administration > Manage Service Applications, and then highlight (don’t click the link) User Profile Service Application. On the ribbon, click Administrators icon.

Make Sure sps3://<server-name> is Included in a Search Content Source

Go to Search Service Application in Central Administration, and make sure you have included sps3://<server-name> in Start Addresses of a Content Source.

Afer you make sure all steps above have been performed, do crawl manually from Central Administration. After crawling is completed, you can perform people search. Now you should see some result.

Source: SharePoint 2013 People Search Result Empty