Holly cow, it has been a while since I posted something. I have been doing much more management than tech stuff as of late, so I haven't had a lot to comment on. HOWEVER, now that my migration to SharePoint 2013 is done and I am starting to create Apps for SharePoint 2013, I have some gotchas to talk about.
I have an On Prem farm, complete with two WFEs, two Application Servers, two Office Web App Servers, two Database Servers, and now two IIS servers for provider-hosted SharePoint Apps.
Configuring you farms for Apps is actually pretty straightforward, but there are a lot of moving parts. Microsoft has really come through with some excellent documentation on how to get everything working. With an On Prem solution, you do have to make sure that you configure your certificates correctly, otherwise S2S auth will not work.
The gotcha that really tripped me up was the configuration of an app domain. What SharePoint does when you deploy a SharePoint hosted app or a provider hosted app with a SharePoint hosted component, is create a sub web off of the web where you are installing your app. This sub web is called the "App Web" and requires you to do some configuration. That configuration is well documented here. What that documentation DOESN'T tell you is that there are some things that you need to consider before pointing your app domain to your existing SharePoint DNS entry. There are some IIS considerations that you need to make.
IIS happily sits on your windows server listening for HTTP traffic. When you configure a new web site, you need to be specific with your IIS binding to make sure that two sites do not conflict. The easiest way to do this, without adding IP addresses to your IIS servers and because we want to have multiple sites listening on ports 443 or port 80, is with the use of Host Headers. The Host Header will tell IIS that any HTTP traffic coming in on a particular port, that has the DNS name of SharePoint.MyCompany.com goes to the correct web site. Most SharePoint deployments make use of Host Headers as they want to host both the Primary SharePoint Web Application and the MySites web application on the same servers in the farm.
Now, when you configure your app domain in DNS, you point the app domain to your primary SharePoint deployment with a wildcard CNAME alias. Here comes the fun part... Your app will have the URL of prefix-APPID.myappdomain.com.
If a wildcard alias points your traffic from prefix-APPID.myappdomain.com to SharePoint.MyCompany.com, AND you have IIS with a host header configured for SharePoint.MyCompany.com, the traffic from prefix-APPID.myappdomain.com will be ignored. Not only will it be ignored, it might get picked up by another web site... Such as the Default Web site that is configured without a host header, and set to respond to any IP address on the server by default. In that case, you will receive a 404 error when attempting to connect to your app, because the default web site is not where you deployed your app web.
Therefore you MUST remove the host header from your primary SharePoint IIS site. This, likely, will cause a conflict with your Default web site, so you must either stop that site, or remove it. What a pain!!
Now, if you have a provider hosted app, that uses a SharePoint hosted app web for authentication and other reasons, you will get strange errors that will have you chasing down the Cross-Domain library rabbit hole. Check your config first to be sure you are going the right direction!
Thursday, October 16, 2014
Monday, February 3, 2014
Creation of Content Types - Rant
The creation of content types is a long, tedious process that nobody likes to do. Especially the users for whom's lives will be made easier because of them. But no one ever wants to participate. Most of the time users get upset. "I don't have time for this!!" Is a common excuse. The snarky remark that I always have to bite back, is "But you have time to search through endless, meaningless documents clumped together in a mess?"
I bite back the remark, because the user is normally only thinking of the workload they have in front of them. The questions I ask pull time away from that workload. The delayed gratification of using the content type to simply information retrieval isn't seen. The questions I ask require a bit of thinking outside the box. What I have found is that people HATE thinking outside the box. They like the box very much.
What really really really gets me is that this type of work exposes all of the office behavior that I detest. The office suckups and yes people will jump on their manager's band wagon. The tattle-tales will complain to their managers, or complain to mine that I am taking time away from work. The lazy will just wait around until someone else does it. The unimaginative will simply hand back what you already know or what you have already told them. And the resistant to change will throw a fit, because this isn't how they have done it in the past.
It boils down to the seemingly universal thought that it is better to put out fires than to do the legwork to prevent the fires from starting in the first place. It also has to do with the fact that most people do not like to think about anything that is more than one layer deep. It is the same thinking that makes everyone want to shove all links to all pages on the "home" page of intranets.
*SIGH*
Back to the grind.
I bite back the remark, because the user is normally only thinking of the workload they have in front of them. The questions I ask pull time away from that workload. The delayed gratification of using the content type to simply information retrieval isn't seen. The questions I ask require a bit of thinking outside the box. What I have found is that people HATE thinking outside the box. They like the box very much.
What really really really gets me is that this type of work exposes all of the office behavior that I detest. The office suckups and yes people will jump on their manager's band wagon. The tattle-tales will complain to their managers, or complain to mine that I am taking time away from work. The lazy will just wait around until someone else does it. The unimaginative will simply hand back what you already know or what you have already told them. And the resistant to change will throw a fit, because this isn't how they have done it in the past.
It boils down to the seemingly universal thought that it is better to put out fires than to do the legwork to prevent the fires from starting in the first place. It also has to do with the fact that most people do not like to think about anything that is more than one layer deep. It is the same thinking that makes everyone want to shove all links to all pages on the "home" page of intranets.
*SIGH*
Back to the grind.
Wednesday, January 15, 2014
Installing SharePoint 2013 Prerequisites On Windows Server 2012 R2
As of right now, the SharePoint 2013 Prerequisite Installer is not supported on Windows 2012 R2. Awesome.
So, here is a way to get around it, but not have to do anything manually.
You first need to ensure that you can run PowerShell scripts on your server. Start a PowerShell session as an administrator and type:
Set-ExecutionPolicy unrestricted
You should know that this will disable all warnings for all PowerShell saved scripts. You should be careful as to what you deploy on your server. Buyer beware.
Now, download all of the prerequisite files:
SQL Server 2008 R2 SP1 Native Client
Microsoft WCF Data Services 5.0
Microsoft Information Protection and Control Client (MSIPC)
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
Windows Identity Extensions
Windows Identity Foundation (KB974405)
Windows Server AppFabric
CU 1 for AppFabric 1.1 (KB2671763)
Put these in a folder, and remember where you put them.
Next you are going to create two PS1 files. The first one will install the Windows Services that you need. The second one will install the Microsoft requisite files.
The first script is fairly simple:
All this does is call the Add-WindowsFeature of the ServerManager module. Just run this guy as an administrator and you are good to go. You will need to restart after the installs... Well, maybe you don't, but I always like to. Anyway, at the end I warn the user that the server will restart in 5 seconds, then I restart it.
The next script uses a couple of different commands. The first command, Unblock-File gets rid of that annoying "Do you really want to run this file?" message that Windows likes so well. We just want to install we don't want to click anything.
The next command is Start-Process. Start-Process is a nifty cmdlet that allows you to enables you start a program, pass it arguement parameters, then tell PowerShell to just hang out until the process completes.
So, what I do here is ask the user where the install files are, that should be the folder that you saved the prereqs that you downloaded earlier in, then runs the installs in the correct order, with the correct arguments. This is very important, especially with the App Fabric setup.
I then restart the server again. You might need it, you might not, I like to because it is a good idea after installing so much stuff, and before you are going to do the BIG install of SharePoint.
That's it! You can either run the manual install from here or run another kind of scripted install. Everything should work, unless the script tries to run the PrerequisiteInstaller.exe program...
So, here is a way to get around it, but not have to do anything manually.
You first need to ensure that you can run PowerShell scripts on your server. Start a PowerShell session as an administrator and type:
Set-ExecutionPolicy unrestricted
You should know that this will disable all warnings for all PowerShell saved scripts. You should be careful as to what you deploy on your server. Buyer beware.
Now, download all of the prerequisite files:
SQL Server 2008 R2 SP1 Native Client
Microsoft WCF Data Services 5.0
Microsoft Information Protection and Control Client (MSIPC)
Microsoft Sync Framework Runtime v1.0 SP1 (x64)
Windows Identity Extensions
Windows Identity Foundation (KB974405)
Windows Server AppFabric
CU 1 for AppFabric 1.1 (KB2671763)
Put these in a folder, and remember where you put them.
Next you are going to create two PS1 files. The first one will install the Windows Services that you need. The second one will install the Microsoft requisite files.
The first script is fairly simple:
Import-Module ServerManager Add-WindowsFeature Net-Framework-Features,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Log-Libraries,Web-Request-Monitor,Web-Http-Tracing,Web-Security,Web-Basic-Auth,Web-Windows-Auth,Web-Filtering,Web-Digest-Auth,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,Web-Mgmt-Compat,Web-Metabase,Application-Server,AS-Web-Support,AS-TCP-Port-Sharing,AS-WAS-Support, AS-HTTP-Activation,AS-TCP-Activation,AS-Named-Pipes,AS-Net-Framework,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs,Web-Lgcy-Scripting,Windows-Identity-Foundation,Server-Media-Foundation,Xps-Viewer –Source D:\sources\sxs Write-Output "Windows features installed. Computer will restart int 5 seconds." Start-Sleep -seconds 5 Restart-Computer -Force
All this does is call the Add-WindowsFeature of the ServerManager module. Just run this guy as an administrator and you are good to go. You will need to restart after the installs... Well, maybe you don't, but I always like to. Anyway, at the end I warn the user that the server will restart in 5 seconds, then I restart it.
The next script uses a couple of different commands. The first command, Unblock-File gets rid of that annoying "Do you really want to run this file?" message that Windows likes so well. We just want to install we don't want to click anything.
The next command is Start-Process. Start-Process is a nifty cmdlet that allows you to enables you start a program, pass it arguement parameters, then tell PowerShell to just hang out until the process completes.
param([string] $SharePoint2013Path = $(Read-Host -Prompt "Please enter the directory path to where your SharePoint 2013 pre-req installation files exist.")) $CurrentLocation = $SharePoint2013Path Unblock-File -Path $SharePoint2013Path\MicrosoftIdentityExtensions-64.msi Start-Process -filepath $SharePoint2013Path\MicrosoftIdentityExtensions-64.msi -ArgumentList "/passive" -Wait Unblock-File -Path $SharePoint2013Path\setup_msipc_x64.msi Start-Process -filepath $SharePoint2013Path\setup_msipc_x64.msi -ArgumentList "/passive" -Wait Unblock-File -Path $SharePoint2013Path\sqlncli.msi Start-Process $SharePoint2013Path\sqlncli.msi -ArgumentList "/passive IACCEPTSQLNCLILICENSETERMS=YES" -Wait Unblock-File -Path $SharePoint2013Path\Synchronization.msi Start-Process -filepath $SharePoint2013Path\Synchronization.msi -ArgumentList "/passive" -Wait Unblock-File -Path $SharePoint2013Path\WcfDataServices.exe Start-Process -filepath $SharePoint2013Path\WcfDataServices.exe -ArgumentList "/passive /norestart" -Wait -Verb RunAs Unblock-File -Path $SharePoint2013Path\WindowsServerAppFabricSetup_x64.exe Start-Process -filepath $SharePoint2013Path\WindowsServerAppFabricSetup_x64.exe -ArgumentList "/i CacheClient,CachingService,CacheAdmin /gac" -Wait -Verb RunAs Unblock-File -Path $SharePoint2013Path\AppFabric1.1-RTM-KB2671763-x64-ENU.exe Start-Process -filepath $SharePoint2013Path\AppFabric1.1-RTM-KB2671763-x64-ENU.exe -ArgumentList "/passive /norestart" -Wait -Verb RunAs Write-Output "Complete. Server will restart in 5 seconds" Start-Sleep -Seconds 5 Restart-Computer -Force
So, what I do here is ask the user where the install files are, that should be the folder that you saved the prereqs that you downloaded earlier in, then runs the installs in the correct order, with the correct arguments. This is very important, especially with the App Fabric setup.
I then restart the server again. You might need it, you might not, I like to because it is a good idea after installing so much stuff, and before you are going to do the BIG install of SharePoint.
That's it! You can either run the manual install from here or run another kind of scripted install. Everything should work, unless the script tries to run the PrerequisiteInstaller.exe program...
Subscribe to:
Posts (Atom)