April 16
Announcing a session at Microsoft WinDays 13

I am honoured to announce my session at WinDays 13, a biggest regional Microsoft conference held in Umag, Croatia on April 22nd - 26th 2013.

The session Successful planning of the SharePoint architecture and how to survive the process will focus on the planning of a solid, reliable and extensible SharePoint 2013 architecture. We will explore the process of gathering requirements and planning a SharePoint infrastructure through a real-life scenario.​

You can find more information about the conference on the official home page (Croatian) at http://www.windays.hr.

I will be happy to meet you there!

 

March 07
Announcing Microsoft Online Services events in Cologne and Munich

I am thrilled to announce an event Microsoft Online Services Business Value and Use in Cologne and Munich, Germany organized by PlanB. GmbH, KPMG and Microsoft Deutschland GmbH. The event will focus on Office 365, Windows Azure and App development.

 

Agenda

​09:00
Check in

09:30
Opening
Tobias Schmailzl
PlanB. GmbH, CEO

09:45
Microsoft Online Services strategy and current developments
Kai Göttmann
BG Lead Server, Tools & Cloud, Microsoft Deutschland GmbH

10:30
Introduction to Office 365 and Azure
Joris Kalz
Partner Technology Advisor, Microsoft Deutschland GmbH

11:15
Data protection & compliance in the Cloud
Dieter Hoffmann
Wirtschaftsprüfer, KPMG AG

12:00
Lunch break

​13:00
Office 365
Eike Heuer
Director Executive Advisory, PlanB. GmbH

13:45
Intune - What Intune offers
Atossa Montaser
Intune Solution Specialist, Microsoft Deutschland GmbH

14:30
Coffee break

15:00
Apps with Azure and Windows 8
Adis Jugo
Technology Advisor, MVP, PlanB. GmbH

15:45
Azure IaaS and System Center
Matthias Reith
Executive Advisor, PlanB. GmbH

16:30
Discussion and conclusion

 

Dates

​16. April 2013
Microsoft Deutschland GmbH
Konrad-Zuse-Straße 1, 85716 Munich
​18. April 2013
Microsoft Deutschland GmbH
Holzmarkt 2, 50676 Cologne

 

Registration

Registration is open until 02. April 2013. You can register by:

e-mail:
events@plan-b-gmbh.com 

telephone:
+49 (7361) 55621-112

March 06
Announcing a session at Microsoft NetWork 3

I am honoured to announce my session at Microsoft NetWork 3, a two-day conference held in a tourist and congress center Banja Vrucica, Bosnia and Herzegovina on April 3rd and 4th 2013.

The session Building a rock-solid SharePoint architecture will focus on the planning of a solid, reliable and extensible SharePoint 2013 architecture. We will explore capabilities offered by SharePoint 2013 and how to use them in the most efficient way through a real-life scenario.​

You can find more information about the conference on the official home page (Bosnian) at http://www.msnetwork.ba.

I will be happy to meet you there!

 

March 05
A new release, a new beginning

A couple of days ago something happened what I was waiting quite some time for - Microsoft released Office 365 for enterprise. Now, I am an Office 365 user for a long time; however, being a P1 customer did have some limitations which were bugging me. Being unable to upgrade to E1 (enterprise plan) was one of them. I was just waiting for a moment Microsoft releases a new wave of Office 365 services so I can upgrade and migrate at the same time - and here they are!

I grabbed my opportunity and decided to move on, to leave the old platform behind and to embrace a new one. I knew for some time now that moving my public home page will require a complete redesign. A Photoshop mockup was done and waiting to be HTML'ed and CSS'ed since October 2012. So, I took some time during a last few days and finally did it.

A new SharePoint 2013 Design Manager is a really a neat thing. It did the whole job for me so I didn't have to do the masterpage myself. Still, I did have to custmize my CSS to support some SharePoint controls, like the navigation for example.

The design is still buggy and not completely done yet. It will get better with the time. But I do hope, it is a good starting point. Still, I decided to move on. It was a time for a change. And I am happy that I did it. Last few days of a hard work did pay off, I believe.

Welcome to my new homepage!

January 22
Beware of KB2756920 and KB2756921

Microsoft released KB2756920 (Windows Server 2008 R2) and KB2756921 (Windows Server 2008 R2 SP1) security patches on January 08. 2013. After the installation lot of Service Applications just stopped working. I had a problem reported with Excel Services Service Application so I started digging through ULS logs. The exception I found wasn't really informative:

01/22/2013 15:30:43.08  w3wp.exe (0x32A4) 0x20A0 Excel Services Application   Web Front End 5240  Critical  There was an error in communicating with Excel Calculation Services http://srvsp03:32843/806754664b1f4c06a45f19fb79495599/AccessService.svc exception: Fehler [Session: User: CONTOSO\spfarmapp]

I turned on exception details for Access Service web service and tried to open the service URL in browser. Then I got the following exception:

System.InvalidOperationException: An exception was thrown in a call to a policy export extension.
Extension: System.ServiceModel.Channels.TransportSecurityBindingElement
Error: Security policy export failed. The binding contains a TransportSecurityBindingElement but no transport binding element that implements ITransportTokenAssertionProvider. Policy export for such a binding is not supported. Make sure the transport binding element in the binding implements the ITransportTokenAssertionProvider interface. ----> System.InvalidOperationException: Security policy export failed. The binding contains a TransportSecurityBindingElement but no transport binding element that implements ITransportTokenAssertionProvider. Policy export for such a binding is not supported. Make sure the transport binding element in the binding implements the ITransportTokenAssertionProvider interface.
   at System.ServiceModel.Channels.TransportSecurityBindingElement.
System.ServiceModel.Description.IPolicyExportExtension.ExportPolicy(MetadataExporter exporter, PolicyConversionContext policyContext)
   at System.ServiceModel.Description.MetadataExporter.ExportPolicy(ServiceEndpoint endpoint)
   --- End of inner ExceptionDetail stack trace ---
   at System.ServiceModel.Description.ServiceMetadataBehavior.MetadataExtensionInitializer.GenerateMetadata()
   at System.ServiceModel.Description.ServiceMetadataExtension.EnsureInitialized()
   at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.InitializationData.InitializeFrom(ServiceMetadataExtension extension)
   at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.GetInitData()
   at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.TryHandleDocumentationRequest(Message httpGetRequest, String[] queries, Message& replyMessage)
   at System.ServiceModel.Description.ServiceMetadataExtension.HttpGetImpl.ProcessHttpRequest(Message httpGetRequest)
   at SyncInvokeGet(Object , Object[] , Object[] )
   at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]& outputs)
   at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc& rpc)
   at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
 

I am not sure what is introduced in these patches but if I had to guess, I would say that security got tightened too much. The fact is that these patches broke my services (and will break yours if you install them). So, I removed the patch, restarted the server and everything was working again.

December 30
Configuring Office 365 with PowerShell - Creating Office 365 instance and configuring DNS

There are few really good articles on Office 365 and PowerShell. I recently had a pleasure to provision and configure one Office 365 instance for one of my clients and to be honest, few of those articles pointed me in the right direction but didn't give me all required information I needed. It is impossible to write a uberarticle and I am definitely not trying to do that here. However, I found few interesting things I would like to share with you. Also, being a lazy guy from time to time, I want to leave few notes to myself for the future. I will definitely need this stuff again :)

At the first, I thought everything will fit into one blog article. However, as more I wrote I was more aware of the fact that this is becoming an monster article. Maybe I am only getting this impression from the amount of text and screenshots I have currently in my OneNote. On the other side, I was never fond of reading huge amounts of text in an single shot so I decided to split the article into (currently) two parts:

  • Creating Office 365 instance and configuring DNS
  • User, distribution and security groups and shared mailboxes management
     
Let's start...

 

Creating an Office 365 instance

To create an Office 365 instance, go to http://www.microsoft.com/en-us/office365/compare-plans.aspx and select your plan. For purposes of this article, I selected Midsize Business & Enterprise option (E3 plan) as a free 30-days trial.

In order to create your Office 365 instance you will need to fill in the form presented after you selected your plan. The form itself is pretty self-explanatory. It is important to enter proper information in all fields; however, the one you don't want to mess with is Country or region. Based on your selection, the provisioning process will select an appropriate data center for hosting your data. Unless you don't want your data hosted half way around the globe (and experience nice little thing called latency and possibly some legal issues depending on country you are living in), be very careful with what you select here. This option can't be changed after sign up.

By clicking I accept and continue button, you will accept terms of use and start provisioning process. You will get in to Office 365 administration quite quick; however, it can take up to 15 minutes for all services to be provisioned.

 

Connecting to Office 365 instance with PowerShell

As an administrator, you can use Windows PowerShell to perform various administration tasks on your Office 365 instance. This is achieved using a wide set of Office 365 cmdlets. To begin using Office 365 cmdlets, you need to install them first. The requirements for installing the Office 365 cmdlets are as follows:

If your environment have met the requirements, download and install one of the following from the Microsoft Download Center:

After you have completed the installation of the Microsoft Online Services Module for Windows PowerShell, start PowerShell and import the module:

Import-Module MSOnline

Now you have an access to all Microsoft Online Services cmdlets. To start administering your instance, you have to use Connect-MsolService cmdlet. To determine to which instance the connection will be made, this cmdlet requires administrator credentials passed as a parameter (also, not to forget, to authenticate the user :)). Let's grab credentials and connect to the service.

$cred = Get-Credential
Connect-MsolService -Credential $cred

 

Now that you established a connection to your Office 365 instance, you can start with...

 

Adding and verifying domains

The next step is to add and verify the domain. The domain I am going to use is already purchased so I am not going to describe this procedure here (anyway, it is out of scope of this article). If you do not have an registered domain, it would be a good time to get one at your domain registrar.

To add a domain, run the following Windows PowerShell cmdlet:

New-MsolDomain -Name adr-it.de

To get the list of the domains associated with your Office 365 instance, run the following Windows PowerShell cmdlet:

Get-MsolDomain

This cmdlet will give us a collection of Microsoft.Online.Administration.Domain objects. The console output will look something like this:

Name                               Status          Authentication
----                               ------          --------------
adrittest.onmicrosoft.com          Verified        Managed
adr-it.de                          Unverified      Managed

Now, note the Status property and values for both domains. Domain adrittest.onmicrosoft.com is already verified as it is been provisioned by Office 365. Domain adr-it.de is not yet verified as we added it manually. Why verification? Imagine that we add something like microsoft.com in here. Now, it is obvious that we do not own microsoft.com domain so there is the reason why Office 365 requires verification. You can safely add to that dozens of possible issues you could run into if it would be possible to register one domain with multiple Office 365 instances. Luckily, Office 365 prevents this.

Now, there are few options to verify domains. As mentioned earlier, as soon as you add domain to your instance, Office 365 is going to generate verification codes. Verification codes are actually in form of DNS entries so you need to add them to your domain. You can use MX or TXT records. TXT records are recommended because they won't influence your current services in any way. MX records, configured improperly, definitely can.

So, where are our verification codes? There is a Windows PowerShell cmdlet for this purpose as well. Run following:

Get-MsolDomainVerificationDns -DomainName adr-it.de -Mode DnsTxtRecord

You will get an output similiar to this one:

Label : adr-it.de
Text  : MS=ms10728978
Ttl   : 3600

This means that we need to create a TXT record for domain adr-it.de containing MS=ms10728978 and time-to-live of 1 hour. For example, if you use BIND as your domain name server, you would add following in the configuration for the adr-it.de domain:

@  3600 IN TXT "MS=ms10728978"

Here is an example how the configuration looks like at my domain name registrer:

 

Some DNS providers however do not allow creation of TXT records. This is where you can use MX records for verification. To get MX verification codes for your domain, run the following Windows PowerShell cmdlet:

Get-MsolDomainVerificationDns -DomainName adr-it.de -Mode DnsMXRecord

You will get an output similiar to this one:

Label        : adr-it.de
MailExchange : ms10728978.msv1.invalid
Preference   : 32767
Ttl          : 3600

To be able to continue with the verification, we will need to create an MX record for domain adr-it.de pointing to ms10728978.msv1.invalid.outlook.com with preference 32767 and time-to-live from 1 hour. It is very important to set preference to 32767 in order to ensure that current mail transport is not affected by this dummy record. To get back to our BIND configuration, you need to add following line to the configuration of adr-it.de domain:

@  3600 IN MX 32767 ms10728978.msv1.invalid.outlook.com.

Again, here is an example how the configuration looks like at my domain name registrer. Note that due to the limitation of the web interface I couldn't set preference to 32767. However, any priority lower than priority of your active MX records (higher value = lower priority) will do the job.

 

Now that we have our records created (and propagated), we can continue verifying domain. To complete domain verification, run following Windows PowerShell cmdlet:

Confirm-MsolDomain -DomainName adr-it.de

By running this cmdlet, you will trigger Office 365 to check for created DNS records. Once Office 365 finds required DNS records it will complete the domain verification process by marking the domain as verified. You can run Get-MsolDomain cmdlet to check this:

Name                               Status          Authentication
----                               ------          --------------
adrittest.onmicrosoft.com          Verified        Managed
adr-it.de                          Verified        Managed

 

Assign domains to Exchange Online and Lync Online

Initially, I though there wouldn't be much to say about assigning domains to services. It was actually supposed to be done with only one call to Windows PowerShell cmdlet Set-MsolDomain. Well, guess what - it isn't so simple. Actually, in current implementation of MSOnline module, there is no way to do this with PowerShell. Why? Well, seems that somebody simply forgot to add the parameter and implement appropriate code. Now, why bother at all? First of all, this article is about configuring Office 365 with PowerShell (yay!). Second thing, imagine you have to assign 50-100 domains to your Office 365 instance. Clicking through Office 365 Admin interface to accomplish this is really not my idea of having a good time.

Nevertheless, there is no way around it. Go to https://portal.microsoftonline.com, log in with your admin account and once you are in the Office 365 administration, click "Domains" link on the left side.

 

Now, click on domain name (in this case, adr-it.de). This will open an page with information about the selected domain. Also, you have an option to change service assignment here: 

 

Now click the Edit domain intent button to open Change domain services dialog. Select Exchange Online and Lync Online and click the Save button. Please note that you can assign domain to either Exchange and Lync Online or SharePoint Online. You cannot assign an domain to all services. We will deal with this later.

 

 

Adding and assigning SharePoint Online domain

By provisioning a Office 365 Enterprise instance three subdomains will be automatically registered with SharePoint Online. Also, three site collections are automatically provisioned:

If we want to create our public home page using Office 365 we will definitely want to use our own domain. It is rather uncommon for your homepage URL to be in the form of adr-it-web.sharepoint.com. It is not representative and it is complicated to remember it. Good news is, we have an option to change this.

So, lets add the new "domain" for SharePoint Online. Actually it is not a domain itself nor a subdomain, it is simply a DNS entry which needs to be registered with Office 365 so that we can use it. We can achieve this by running following  Windows PowerShell cmdlet:

New-MsolDomain -Name www.adr-it.de

This cmdlet will register www.adr-it.de with Office 365. Let's take a look at the cmdlet output:

Name                               Status          Authentication
----                               ------          --------------
www.adr-it.de                      Verified        Managed

Note the Status property and its value. From Office 365 perspective this domain is already verified. Why? Well, although we didn't got any verification codes and we didn't run Confirm-MsolDomain cmdlet, we did this for the parent domain (in our case adr-it.de) meaning we already proved we own the domain.

Now that we added the subdomain, we need to assign it to SharePoint Online service. Unfortunately, we can't achieve this with PowerShell, as earlier described. To complete this task we will have to go to the Office 365 administration one more time.

Now, navigate to https://portal.microsoftonline.com, log in with your admin account and once you are in the Office 365 Admin interface, click the "Domains" link on the left side.

 

Click on the domain name (in this case, www.adr-it.de). This will open an page with information about the selected domain.

 

Now click the Edit domain intent button to open Change domain services dialog. Select SharePoint Online and click Save.

 

We just registered the new SharePoint Online domain. To use it, we will need to go to the Admin Overview page in Office 365 Administration, click Manage link for SharePoint in the Microsoft Office 365 group and click Manage Site Collections link.

 

Click New button, click Public Website, select appropriate URL and other options in the presented dialog, click OK and you are (almost) good to go. The last part of configuring Office 365 domains is to configure your domain with appropriate CNAME, MX, TXT and SRV records.

 

Configuring DNS records

At this stage, Office 365 is fully configured for use with your domain. The only thing missing is to tell clients where to connect and this is done by adding and configuring an couple of DNS entries.

Navigate to https://portal.microsoftonline.com, log in with your admin account and once you are in the Office 365 Admin interface, click the "Domains" link on the left side. Click the domain name and click DNS settings link on top of the page. A page with information on required DNS records and settings will appear. Follow these instructions carefully (do the same for all domains and subdomains you've registered) and enter these information in your DNS configuration or forward it to your domain name registrer for configuration. Once these records are created, your mail will start flowing, your Lync buzzing and you and your colleagues collaborating. Ok, for the last part you will need few more accounts. I will describe this in one of my next posts.

Stay tuned...

December 06
Provisioning SharePoint 2013 Search Service Application via PowerShell

Well, it is a quite some time since my last post. And yes, I know! I promised and still didn't made my second post on Enterprise Search in SharePoint 2010. Well, I can't help myself. This SharePoint 2013 hype got me as well. It doesn't mean I won't do what I promised. It's only postponed (again). Priorities must be well defined :)

This article has a history on its own as well. I started writing it somewhere during public preview, left it in OneNote and forgot it. Now I finally got some time to catch a breathe again and continue playing with RTM bits. So, last night I got myself into configuring Search Service Application in SharePoint 2013. I think it is a good starting point on fetching design changes. And we have some significant changes in this new version. Search engine got a full new facelift, under the hood tuning, call it how you want - it is just cool.

So, what actually changed? Let's answer this question by comparing topologies first:

 

SharePoint 2010

SharePoint 2013

Administration component

Administration component(s)

Crawl component(s)

Crawl component(s)

Index component(s)

Index component(s)

Query processing

Query processing component(s)

 

Content processing component(s)

 

Analytics processing component(s)

 

So, we have some new fellows in here. Also worth to mention is, that query and crawl topologies are merged now into a single topology, simply called "search topology" now.

So, let's start creating a brand new Search Service Application. We'll define some constants for a start.

$serviceAppName = "Enterprise Search Service Application"
$serverName = "CONSP01"
$adminServer = $serverName
$crawlServer = $serverName
$queryServer = $serverName
$indexServer = $serverName
$analyticsServer = $serverName
$contentProcessingServer = $serverName
$dbServer = "CONSP01"
$searchServer = $serverName
$searchDBName = "SP2013_Enterprise_Search"
$svcAppPoolName = "SharePoint Web Services Default"
$indexLocation = "D:\SharePoint2013\index"

Now, it is worth of mentioning, that I am creating a search topology using only one server. This is, of course, not a limitation. Search topology is pretty scaleable. It was already in SharePoint 2010 and it got even better in SharePoint 2013. At the time of writing this article, tests on RTM bits were made to provide a general gudance on topology, sizing and capacity planning.

Provisioning of the search service application will create 4 databases:

  • SP2013_Enterprise_Search
    This is a search administration database. It contains configuration and topology information.
     
  • SP2013_Enterprise_Search_AnalyticsReportingStore
    This database stores the result of usage analysis
     
  • SP2013_Enterprise_Search_CrawlStore
    The crawl database contains detailed tracking and historical information about crawled items
     
  • SP2013_Enterprise_Search_LinksStore
    Stores the information extracted by the content processing component and also stores click-through information.
     

So, let's get back to business. We need a Search Service managed account. First of all, we will check if the account is already registered as a managed account and create it if it isn't.

$searchCred = "CONTOSO\sp_search"
$searchPwd = ConvertTo-SecureString -String 'Pass@word1' -AsPlainText -Force
$cred = Get-Credential $searchCred
$searchSvcAccount = Get-SPManagedAccount $cred.UserName -ErrorAction SilentlyContinue

if ($searchSvcAccount -eq $null)
{
  
$searchSvcAccount = New-SPManagedAccount $cred
}

Next thing to do is to configure a search service instance. We can set a default index location here and provision it. Well, actually DefaultIndexLocation parameter is obsolete now. We can however, set the index location during the creation of the index component later on.

$searchSvc = Get-SPEnterpriseSearchServiceInstance -Local
if ($searchSvc -eq $null)
{
  
throw "Unable to retrieve search service"
}

# set Search Service parameter
$searchSvc | Set-SPEnterpriseSearchServiceInstance

if ($searchSvc.Status -ne "Online")
{
   $searchSvc | Start-SPServiceInstance
}

 

Now it is time to configure some additional settings in the search service, like service identity, e-mail, connection time out, proxy and preformance level.

$svc = Get-SPEnterpriseSearchService
Set-SPEnterpriseSearchService `
  
-Identity $svc `
  
-ServiceAccount $searchSvcAccount.UserName `
  
-ServicePassword $(ConvertTo-SecureString -String 'Pass@word'   
   -AsPlainText
-Force) `
  
-ContactEmail "searchadmin@contoso.com" `
  
-ConnectionTimeout "60" `
  
-AcknowledgementTimeout "60" `
  
-ProxyType "Default" `
  
-PerformanceLevel "PartlyReduced"

From the service perspective, everything is up and running. Next step in the provisioning process is to create Search Service Application.

$searchApp = Get-SPEnterpriseSearchServiceApplication $serviceAppName -ErrorAction SilentlyContinue

if ($searchApp -eq $null)
{
   $saAppPool = Get-SPServiceApplicationPool | where { $_.Name -eq $svcAppPoolName }
   $searchApp = New-SPEnterpriseSearchServiceApplication -Name $serviceAppName -ApplicationPool $saAppPool -DatabaseServer $dbServer -DatabaseName $searchDBName
}

Now, this is where things start to differ from SharePoint 2010. We had two topologies earlier, a crawl and query topology. In SharePoint 2013 everything merged into one topology - a search topology. Still, some habbits never change. Creating new search service application will create a search topology as well and activate it. As we cannot add components to an active topology, we will have to create a new search toplogy and add components there, concluding this with a removal of an old topology. This is a similiar behavior as in SharePoint 2010 where we had to create new crawl and query topologies and decomission the old ones.

$initialSearchTopology = ($searchApp | Get-SPEnterpriseSearchTopology)
$searchTopology = ($searchApp | New-SPEnterpriseSearchTopology)

Start adding components. We have following components:

  • Admin
  • Crawl
  • Index
  • Query Processing
  • Analytics
  • Content Processing

 

We have two new fellows here - Analytics and Content Processing. The reason is that the Analytics is now a part of Search Service Application, it is not a Service Application on its own anymore. Let's start an admin component:

$adminSearchInstance = Get-SPEnterpriseSearchServiceInstance $adminServer

if ($adminSearchInstance.Status -ne "Online")

{

    $adminSearchInstance | Start-SPServiceInstance

}

$admin = $searchApp | Get-SPEnterpriseSearchAdministrationComponent

$admin | Set-SPEnterpriseSearchAdministrationComponent -SearchServiceInstance $adminSearchInstance

$admin = ($searchApp | Get-SPEnterpriseSearchAdministrationComponent)

while (-not $admin.Initialized)

{

    Start-Sleep 10

    $admin = ($searchApp | Get-SPEnterpriseSearchAdministrationComponent)

}

Start-SPEnterpriseSearchQueryAndSiteSettingsServiceInstance $adminServer

$adminSearchInstance = Get-SPEnterpriseSearchServiceInstance $adminServer

$adminComponent = New-SPEnterpriseSearchAdminComponent -SearchTopology $searchTopology -SearchServiceInstance $adminSearchInstance

 

Create a crawl component

$crawlInstance = Get-SPEnterpriseSearchServiceInstance $crawlServer
$crawlComponent = New-SPEnterpriseSearchCrawlComponent -SearchTopology $searchTopology -SearchServiceInstance $crawlInstance

Create a query processing component

$queryInstance = Get-SPEnterpriseSearchServiceInstance $queryServer
$queryComponent = New-SPEnterpriseSearchQueryProcessingComponent -SearchTopology $searchTopology -SearchServiceInstance $queryInstance

Create a index component. We will use RootDirectory parameter to set the index location.

$indexInstance = Get-SPEnterpriseSearchServiceInstance $indexServer
$indexComponent = New-SPEnterpriseSearchIndexComponent -SearchTopology $searchTopology -SearchServiceInstance $indexInstance -RootDirectory $indexLocation

Create a analytics component

$analyticsInstance = Get-SPEnterpriseSearchServiceInstance $analyticsServer
$analyticsComponent = New-SPEnterpriseSearchAnalyticsProcessingComponent -SearchTopology $searchTopology -SearchServiceInstance $analyticsInstance

Create a content processing component

$contentProcessingInstance = Get-SPEnterpriseSearchServiceInstance $contentProcessingServer
$contentProcessingComponent = New-SPEnterpriseSearchContentProcessingComponent -SearchTopology $searchTopology -SearchServiceInstance $contentProcessingInstance
 

A new topology is created, now it is a time to activate it. 

$searchTopology.Activate()

The old topology will be automatically deactivated, however we need to fetch an object again and delete old topology

$initialSearchTopology = ($searchApp | Get-SPEnterpriseSearchTopology | where { $_.TopologyId -eq $initialSearchTopology.TopologyId } )
Remove-SPEnterpriseSearchTopology -SearchApplication $searchApp -Identity $initialSearchTopology

At the end, register a service application proxy

$searchProxy = New-SPEnterpriseSearchServiceApplicationProxy -Name "$serviceAppName Proxy" -SearchApplication $searchApp

Now you have a Search Service Application up and running. :) 

July 16
SharePoint 2013 Preview and Office 2013 Preview available for download

Steve Ballmer announced Office 2013 few hours ago. During his presentation, Office 2013 Preview was released for a download. SharePoint 2013 Preview and documentation just got uploaded as well.

Here are few useful links:

July 15
MCM SharePoint 2010 - Part II

< Part I

It is more than two months since I started writing about MCM program. And lot of things happened. So, to continue at the point where I stopped last time - although I enjoyed my screening interview I had two quite hard days thinking about if I am going to be accepted or not. And Brett sent the results, as promised, within 48 hours and surprise, surprise - I managed to get in!

 

Onsite part

Now it was a time to think about logistics. Due to my nationality I needed to react really fast to get USA visa. Tickets were booked and I managed to get a room in Homestead for the first week. Luckily I had no complications to get visa (I suppose, a invitation letter from Microsoft helped as well :)) and I was on the plane to Seattle on April 7th.

We had a kick-off meeting the day after my arrival. Brett explained to us what is waiting for us in the coming 12 weeks. Finally, the whole gang was at the same place for the first time. All in all, 27 finest from all around the world, not only in their area of expertise but great folks in general - I am really glad I had a chance to get to know them (howdy, folks!).

I attended a hybrid rotation. Unlike classic rotations which take place 3 week onsite in Redmond, hybrid rotation is made of an one week onsite part in Redmond and 11 weeks of remote delivery. We started on Monday, April 9th, at 8:00am. Non-Microsofties like myself needed to get IDs first so we had to be there an hour earlier. Apart from that and changing topics (and I can assure you, we went through LOT of stuff first week) each day of our onsite part was quite similliar: start at either 7am or 8am, few short breaks during a day and one "big" break for a lunch (typically 20-30 minutes).We spent our whole days on sessions and hands on labs. The days were very long - although sessions were usually over between 6pm and 8pm we had to stay and do our "homework". We've got few hands on labs to complete until end of the week. So, we ended up working until midnight or even longer - every single day.

I was surprised how fast the time went by. We worked on our HOLs on Saturday as well and had a wrap-up at the end of a day. After that, an onsite part was officially over and we went to Parlor Billiards & Spirits to celebrate. It was a night to remember :)

I stayed in Seattle for next couple of days. A short vacation, well deserved. I really enjoyed my time there, unfortunately my visit had to come to an end. I missed my kids, my wife and my dog. I was heading home on April 19th.


Remote delivery

Remote delivery started during my visit to Seattle. I had an impression that it won't be a big issue to manage but then again, I was wrong. Being in Seattle during a first week of remote delivery, I didn't have much else to do so it was a breeze. The real deal started a week after, when I was back to work. Next 11 weeks were organized as following:

  • most Mondays and Tuesdays: onsite at customers offices until 3:30pm, remote deliveries at 5:00pm with duration of 4-4.5 hrs.
  • the rest of the week: working until 6pm, HOLs and session reviews for the rest of the evening (and weekends)

 

The amount of material was just humonguous. We covered lot of SharePoint topics, not only ITPro and architecture but lot of development topics as well. We had an honor to be teached by the best of the best in the SharePoint and SQL Server product group and community. Most of them are MCMs as well. And, although I was usually drop dead tired I wanted to hear more and more of each session. You don't get the chance to peek behind the curtains of a product every day :)

I mentioned hands on labs earlier. They were great addition to sessions. Each of them took few hours to complete, some of them I did even few times just to make sure that I got everything right. Regarding hardware, each and every of us had his own blade (PowerEdge 710) with 72 GB RAM and ca. 4TB disk space. Not sure how many cores we had (forgot to take a look) but it was more than enough. We could start more than 20 VMs and everything was just working as it should.

 

Exams

Our last session ended on June 19th. We had only few days to go through all the material again as our knowledge exam was scheduled directly a week after the last session. I did my exam on June 26th. Let me tell you something about MCM knowledge exam - it is not your average MCP Prometric exam, y'a know... We had 4 hours for 100 questions, divided in 3 sections. Each and every question was really tricky. The questions are well written, answers even better. You really need to know your stuff and to read carefully to get the answer right. I took the exam from home as there are enough security measures to insure we are not cheating. I got my results just few days later - I managed to get it right!

But, it was not over yet. In order to gain a MCM certification there is a qualification lab to go through as well. I did mine on July 11th. This was a really hard and great experience at the same time. I had 8 hours for lab itself. This is a practical exam so we got our virtual servers and a bunch of tasks to do. All tasks were manageable however good planing and time management is required here. And you need to stay focused, which became almost impossible after 7 hours with almost no breaks. I didn't do all tasks, I just needed additional time and ability to focus.

After the qualification lab I had the same question I had on the start of this journey - Am I good enough? It was hard to wait for an answer the next few days. I hoped for the best. And on Friday, July 13th 2012 the answer finally came. All the hard work paid itself off.

I am a Microsoft Cerfitied Master for SharePoint 2010 now!

May 20
A little bit of Host Header Managed Paths love... or how (not) to break your Publishing Template provisioning

With SharePoint 2007, we had a possibility to create host header site collections. SharePoint 2010 extends this possibility by allowing us to create multiple site collections within one logical host header URL space. This means, not only that you can have for example site collection under http://hosting.adrit.local (as seen in SharePoint 2007) but you can have now additional site collection(s) in location like http://hosting.adrit.local/sites/site1.

I suppose the main driver to bring such an improvement was multitenancy. In a multi-tenant scenario, you can have something like:

  • http://www.tenant.com as a main site collection
  • http://www.tenant.com/mysite for a tenant-specific MySite Host
  • http://www.tenant.com/mysite/personal/* for personal sites
  • http://www.tenant.com/admin for tenant admin site collection
  • http://www.tenant.com/search for a search center (bad idea, keep reading :))

 

and so on. To be able to create these site collections, you will need to have appropriate managed paths in place.

Managed paths defined for a Web Application itself just won't work. We need to define here Host Header Managed Paths. Now, as for Host Header Site Collections, there is just no UI which you can use to configure this. The only way to create managed paths for Host Header site collections is through PowerShell. Cmdlet that will be used for this purpose is the same cmdlet as for creating regular Managed Paths: New-SPManagedPath. The switch you want to use for this is HostHeader. Example:

New-SPManagedPath -RelativeURL admin -HostHeader -Explicit

Explicit switch specifies that the new managed path represent a explicit inclusion. If ommited, a wildcard path will be created.

Now, testing various scenarios, I figured out that you *REALLY* need to think about naming and various naming space collision scenarios. Why? Because, unfortunately, managed paths created this way will be applied over *ALL* web applications. The reason for that is that host header managed paths are not bound to any web application. Example:

New-SPManagedPath -WebApplication http://hosting.adrit.local -RelativeURL testMP -HostHeader

will cause following error:

New-SPManagedPath : Parameter set cannot be resolved using the specified named parameters.

If you omit the WebApplication parameter, the cmdlet will run successfully.

A really bad example of managed path naming and good collision example is "search" managed path, as mentioned earlier. If you create this one you will break site provisioning using Publishing Template all over your farm, at least for the root of your web applications. Why is that? Well, Publishing Template will try to create a search center within Search subsite. As /search is already reserved via (host header) managed path... *bang* - provisioning fails.

One more thing - you won't be able to see these managed paths via Central Administration UI. Im order to see them you will have to run following cmdlet:

Get-SPManagedPath -HostHeader

1 - 10Next