As I started to configure our new SharePoint 2013 farm today I came across a problem when running the pre-requisites tool when it was attempting to install “Application Server and IIS Web Server roles” which resulted in very little in terms of error messages apart form “configuration error”.
After much searching and reading on Technet I wasn’t able to find out exactly what roles and features needed to be install so I could do this step manually. I resorted to simply adding most of the features I assumed would be needed based on what I remembered from a preview version install and discovered that it was due to .Net 3 not being present on the default install of Windows Server 2012. In order to install .Net 3 you have to have the original disk (or network location) where the files are stored in “:\Sources\SxS”.
After I managed to install .Net 3 manually, the pre-requisites tool then progressed as expected.
UPDATE: This was incorrect, see below instead If you are looking to install SharePoint 2013 on Windows Server 2012 I would recommend leaving the Windows Server 2012 disc in the drive or mounted, and using the new “mount iso” capability in 2012 to mount the SharePoint 2013 media so that the default sources location is available. If however, you end up in a similar situation, simply install .Net 3 manually using the “Add Roles or Features” as normal and this will prompt you to specify a location where the Side By Side files can be found.
I will hence forth refer to this as “SharePoint 2013 Gotcha #1″ (Although technically its Windows Server 2012 being difficult)
Update: I had an opportunity to check this again and found that having the disc in the drive simply isn’t enough. Manually install the following using “Add Roles and Features” and specify the SxS (Drive:\Sources\SxS of install media) location when the notification appears in the roles and features wizard:
One of the key things I’m liking with Windows Server 2012, is the new Server Manager. The new version is alot more useful than that of Windows 2008 and Windows 2008 R2 in that it appears to work out of the box, where as the previous involved alot of “tweaking” to get WinRM working.
This has a huge impact on the use of Server 2012 Core Edition, which unless you love doing everything on the command line or in PowerShell is pretty annoying to even get started with. However, the new server manager allows you to add roles and features from your local workstation along with launching applicable role tools right from the UI.
I’ve always likes the idea of Windows Server Core, but the practicality of managing it has always been and issue along with role limitations, although this appears to have also been “fixed”.
I Have always had a problem with IIS Manager using SQL Aliases when using the built in .Net membership providers (mainly cause its handy to test and setup the initial FBA user) but never managed to get down to the cause of the issue, just took it as one of those things.
Luckily it was never really that important to resolve so it got left as specifying the alias in the web.config file did appear to work fine. However, a colleague had a similar problem with Visual Studio when trying to regenerate a database layer, which was a bit more of an issue due to the storing of the string.
After a bit of googling we managed to track down the issue:
If like me your happy using the “cliconfg” command to specify aliases (mainly because its included in Windows Server 2008 R2 and there’s no need to install the SQL Native Client manually), its important to understand that the architecture is important, this is where “Native Client” should have given the hint. The problem is that the 32bit client and the 64bit client store their registry keys in different locations, therefore adding an alias in one doesn’t add it to the other. IIS Manager and Visual Studio are both 32bit applications and therefore use the 32bit aliases, however running the “cliconfg” command from run or a command prompt on a 64bit machine unsurprisingly loads the 64bit version of the client configuration tool. Therefore, if you run into this issue, you should run “c:\Windows\SysWOW64\cliconfg.exe” for the 32bit version.
Note: I have no idea why 32bit applications are stored in SysWOW64 and the 64bit ones in System32… appears like it should be the other way around to me?!
Everytime I have to open log file I always wished it would update on its own so I didn’t have to close it and open it again. I know applications like visual studio notify you when a file updates but its usually not a good idea to install it on the production machine and across the network access can be painful.
In comes PowerShell to save the day… And its install on pretty much all modern windows servers these days as standard.
Will print out the content of the log and wait at the bottom, when new lines are added the screen is too. How did it take me so long to find this!
For those of you familiar with linux this is similar to
There is a bug in SharePoint 2010 that can cause an entire site collection to become corrupt which can only be fixed by restoring a backup. This issue is only likely to occur with code in custom solutions as the equivalent manual actions through the web interface do not cause the same issue, therefore general SharePoint use is not affected.
When does the issue occur?
When using the SharePoint Object Model or PowerShell to programmatically set permissions on a sub site (SPWeb) by first breaking role inheritance.
At this point the site collection will be fine, however if you then create a List or Document Library you will notice that the permissions won’t be inherited as they usually are. If you select to then inherit the permissions from the parent sub site (SPWeb) the site and any other content in the site collection including system pages will not be accessible. The server will throw a HTTP 500 error and will not give any specific reason in the Event Log or the ULS logs.
PowerShell commands cannot be run on the Site Collection
No administrative functions can be carried out on the Site Collection through Central Admin
Details for the site collection cannot be viewed through central admin
Access to the settings or data through the SharePoint API will not be possible
Any sites or sub-sites in the collections will not be accessible
As of 20th July 2012, we are un aware of a fix having been released for this issue.
If you have ever decided to make a blank site just because you know your going to start from scratch then find out that alot of the features your used to in a team site simply arn’t available or don’t work as they do in the team site?
SharePoint has a number of hidden features which you can’t activate via the interface. If you have decided to use managed meta data and run into issues then its probably because the hidden “TaxonomyFieldAdded” feature isn’t available.
The feature can be activated via powershell using the following:
Unable to resolve users with either the standard user checker or the people picker (the people picker could also be that it hasn’t been configured for your provider so check that too) but users are being authenticated.
If you have specified that your FBA connection string is to use integrated security then make sure that you have granted access not only for the machine but also the SharePoint farm account and the account which is running the SharePoint sites application pool