SharePoint 2013 Group Calendar limitations

In my situation, after successful configuration of Outgoing and Incoming e-mail, I was able to send e-mails and meeting requests from my Outlook to SharePoint libraries and lists, including SharePoint Calendar.
Everything worked except meeting requests to the calendar sent via e-mail . They were successfully delivered to the Events' List but not showing up in the actual Calendar.

I knew that it was nothing to do with my e-mail configuration. The messages WERE DELIVERED. I focused on SharePoint and discovered that if I switched off the option of 'Use this calendar to share member's schedule' in Calendar Lists's Settings (List name, description and navigation), a meeting request I would send to the Calendar via its e-mail address would show up in a Calendar View.

Do not worry, you are not loosing a lot by setting NO to 'Use this calendar to share member's schedule'.
Microsoft's Article on Group Calendar will tell you all the beautiful bits you can do with this option. It will not tell you though that once you add people to your 'Share Calendar' and navigate away from the page or refresh it, you will loose the users you have just added. You will have to add them manually again! Strange!

Here is my situation:

'Shared Calendar A' is the main departmental calendar on a home, top level page in the site collection with overlays for other calendars in different sites (department functions) within this site collection.

Currently, when a User1 adds an item to the 'Shared Calendar A' (group option switched off), it will show up to User2 when he opens up the 'Shared Calendar A'.

When a User1 adds an item to a 'Function Calendar A', it will show up in an overlay on the 'Shared Calendar A' JUST FOR this User1.

Similarly, when a User2 adds an item to a 'Function Calendar A', it will show up in an overlay on the 'Shared Calendar A' JUST FOR this User2.

So far, we have established that overlays work only for the current user.
It would be useful if users could see each other's (colour-coded?) calendar items (overlays) for each function in the department's 'Shared Calendar A' just as if the Group Calendar option was switched on.
Somehow, we have to replicate the functionality of a group calendar without using OOTB 'Group Calendar' function of SharePoint Calendar because we want items sent by e-mail to display in the calendar!
What if every item created by any user in any 'Function Calendar' within site collection was copied across to the 'Shared Calendar A' automatically so everybody can see it? ! I'm not sure about colour coding though- it might not work but logic is definitely there.
I know what you say: Workflow! But not a basic workflow. To copy items across sites in a site collection, you need a Visual Studio. You cannot develop such a workflow in SharePoint Designer for example.

But wait a minute... Will it not be confusing for the user who will see his/her coloured calendar overlays in their view of 'Shared Calendar A' along with a blue duplicated item copied to a 'Shared Calendar A' from a given 'Function Calendar'?

Maybe we should look at the situation from a different angle?
How about switching a 'Group Calendar' option back on, what would mean:

• loosing automatic display of items sent by e-mail to the calendar, but:
• colour coded calendar overlays would work on a 'Shared Calendar A' for the whole group of users ONLY IF you add a user to the group calendar (note: that user will be stored there temporarily)

..and then manipulate the views to show events items in a calendar list (it must be a way)!

As of manipulating the views, I found this Laura Walker's reply to one of the questions posted on a SharePoint forum:

'When you defined the calendar view, which options and fields did you select for the Columns section of the view definition? Did you use a single date field or the interval option? And for the selected date field(s), is/are the field(s) required? And is/are the field(s) for the missing items populated?

(...)Try checking the portion of the view definition. Perhaps the view has the wrong columns setting.

And here's another test to try. If you have date fields of beginning date and end date, and you define the calendar view to show items in the range of end date to beginning date (instead of from beginning date to end date), you can also make some items not show up. In fact, the only
items that DO show up in this case are the ones where end date and beginning date are BOTH populated and have the same value. If end date is left blank, the item is excluded from the view. And if the end date is later than the beginning date, the item is excluded from the view'.

Let's investigate:

Properties of the item visible in a Calendar View

 

Properties of the e-mailed item showed in 'Events' list but not in Calendar View

Do you see what I see?
Once I edited the event not showing in a Calendar View to include 'Attendees', that item miracleably appeared in the Calendar.
In addition, the column 'Function' was a metadata column which was set to required. I changed that so now it is optional.

Now, it is time to investigate the issue of Attendees and other columns in an e-mailed Meeting Request!
I removed 'Required' from any column both for Schedule and Event content types. This eliminates the situation where the item would not be saved to the calendar due to Outlook not populating every field required. Plus, as mentioned before, I deleted a Metadata column from Schedule and Event content types as sometimes metadata does not play well with other functionality in SharePoint.
IT STILL DOES NOT WORK! Events are stored in 'Events' List but not showing up in Calendar View.

I clicked 'Edit Properties' 'of the item stored in Events but not showing up in Calendar View. It does not show my Attendees but in Outlook I have 3 of them (inc. this SharePoint Calendar) for the same item. The Attendees field is not required so it should not be much of a problem at least in one aspect.
For the time being I focused on the dropdown for a Content Type- Schedule vs. Event:

We know that by populating the 'Attendees' field in the Schedule form, the item will be included in a Calendar View. To further investigate potential causes of the problem, let's connect this SharePoint 'Shared Calendar A' to an Outlook personal calendar and see if dragging and dropping such an Outlook generated item from personal to SharePoint calendar would in fact populate a SharePoint Calendar view.
(If you are an Admin of the site and your 'Connect to Outlook' button on the ribbon is disabled, refresh the page and try it again or copy the Web Address of the Calendar from its settings page, paste it in the address bar on another tab and try connecting to outlook again. This issue is most probably caused by a 'Minimal Download Strategy' feature enabled on a site level'.)

So, once you connected your SharePoint calendar to your Outlook, just generate a new appointment in your personal calendar and drag & drop to copy it to the SharePoint calendar like this:

First thing I saw was:

Then I noticed:

Despite that, the item was displayed in a 'Shared Calendar A' calendar view with the prefix 'Copy:' to it. See below:

I ignored a personal calendar in Outlook on the left and created a Meeting Request as a User1 in a connected SharePoint 'Shared Calendar A' on the right without adding a 'Shared Calendar A' e-mail address to the list of attendees. I only added a User2 as an attendee.

On MS Help Forum I found that:

'This error refers to the fact that a SharePoint list calendar isn’t capable of tallying responses.  SharePoint list calendars by design do not tally attendance.  In order to tally responses you would need to use a Meeting Workspace.'

Mind you a Meeting Workspace has been depreciated in SharePoint 2013 :)

I sent it anyway. I then logged in as a User2 to whom I just sent the request and accepted it. Nothing happened for a while.
After User1 clicked 'Send/Receive' in outlook, the User1 (originator) could see the item in 'Shared Calendar A' on a SharePoint site.
User2 could not see his meeting that he/she just accepted in SharePoint calendar view, but it was visible in 'Event List' (so same problem here).
User2 could also see his accepted meeting request in his/her personal calendar in Outlook! If User2 would drag and drop this meeting into his connected SharePoint 'Shared Calendar A' in Outlook, this item would appear in a calendar view in SharePoint with a prefix 'Copy:'

It is called a seamless integration, isn't it? I just cannot wait until I would have to explain to my users what they can and can't do between SharePoint and Exchange! (not!).

Going back to the issue of e-mailed meeting requests not showing in Calendar View but only in events List- i am not giving up!

I deleted the 'Shared Calendar A' as it might have been a custom list (created from a template used elsewhere). I then cleared the recycle bin and went back to the main root page of the site collection. I added an app being a calendar, enabled 'Group Calendar' option and added an e-mail address to the Calendar List.
Same problem - items are sent to the Event List but are excluded from the Calendar View.

I started recreating the Overlays and out of curiosity, I started from the Exchange Overlay (for auto syncing your personal calendar).

[side note _________________________________________________________________________

You need a web access to your Outlook (OWA), please see MS Article describing the process as well as its limitations [e.g. works only with a user who is currently logged on].

When you successfully created an Exchange overlay in your SharePoint Calendar, you might see events shown in a 'Free/Busy/Tentative' format like that:

This is caused by the default setting for the account in Outlook. In Office 2010:
Go to File -> Options -> Calendar -> Calendar Options (section) -> Click 'Free/Busy Options' button and change the Read options according to your preference, e.g. 'Full Details'
Note that this Exchange overlay in SharePoint is just a projection of your OWN, personal calendar in the Exchange and you cannot edit items shown in this overlay in SharePoint.

In addition, if it happens that the User2 has his Exchange overlay configured on his 'Shared Calendar A' and you (User1) try to add that User2 to the Group calendar to see his/her schedule you will receive this error:

'E-mail address is empty. you should set Exchange e-mail address into your user profile to retrieve calendar data from Exchange server'

It looks like the functionality breaks when you attempt to add another user.
To summarise, it is not a proper overlay of calendars like with other calendars within SharePoint. It is just a raw display of Exchange items with which you cannot do anything.

_____________________________________________________________________end of side note]

Anyway, an Exchange Overlay was done just as a proof of concept. Maybe someone, somewhere would have a requirement for it.

Let us go back to the request items sent via Outlook not showing in Calendar view as we did not resolve that, did we?
We have managed to deepen the problem after we deleted the old 'Shared Calendar A' and created a new one from scratch from a default calendar app in SharePoint! Now, when you add an item to the calendar (no matter how, via 'Add' link on hover, 'New item' from the ribbon or 'New item' from Content and Structure), nothing happens in the Calendar View (tested with multiple browsers). Everything goes into 'Event Lists'! WTF!
Ok, an 'Event' Content Type does not seem to work so I added a 'Schedule' Content Type to the calendar list and created a new Schedule item. It did go to the Calendar View.

In summary, I committed this diagram to graphically attempt to explain this wonderful integration between SharePoint 2013 and Outlook 2010:

I am moving to something else, watch out for updates on this post as I am not giving up!











  

SharePoint 2013 Incoming and Outgoing E-mail

The configuration of Incoming and Outgoing e-mail in SharePoint 2013 should be a simple task. Well, on paper.
In our scenario, we could not take advantage of the Site Mailboxes- a cool new feature of SharePoint 2013 which to some extent enriches the functionality of Incoming e-mail configured on List/Library level. In order to use Site Mailboxes, the requirement was to use an Exchange Server 2013. Since we own an Exchange 2010, we proceeded with configuring Incoming and Outgoing e-mail features.

#################################################################################

SharePoint 2010/13 allows you to leverage Active Directory Domain Services (AD DS) so that contacts that are created when you email enable document libraries or lists are stored in a designated Organizational Unit within your AD DS infrastructure.  So why would you want to enable Directory Management Service?  Purely for the fact that by storing these contacts in AD, you are allowing your users to locate email enabled libraries and lists easily from within their Outlook Address book.

Copyright SharePoint George blog

#############################################################################################

We will not configure such a Directory Management Service in our production due to a simple reason. It is impossible to define a number, names and specifications of our lists and libraries. The system is going to be developed in instalments and every department will be responsible for their own site. Users will either simply know the e-mail address of the list/library, it will provided on pages (object descriptions) or it will be stored in their Outlook sent history. Storing these e-mail addresses in AD would be difficult to manage and would require a constant input After all, the features are pretty powerful in their own limitations (? strange saying) and enable the following if configured in an automatic mode:

Incoming E-mail:

• Lists and Libraries can be assigned a unique e-mail address for users to send e-mails and attachments to without even opening SharePoint site:

In the example above, the user has sent an e-mail 'Another test' and CC'd this SharePoint Library by adding its e-mail address. The e-mail does not have to be CC'd. It could be sent directly. As you can see, the e-mail has been stored in the library. Similarly, if the user attached a file to his e-mail, it would have been stored in the library along the actual .eml file.

You can group these e-mails and attachments in folders, sort them by e.g. sender etc. Everything is configured in List/Library Settings under communication heading (Incoming e-mail setting). 

Outgoing E-mail:

• Alerts- users can set up alerts on List, Libraries, Documents, Discussions and can be notified by e-mail about any changes to the object

• Admin messages- Admins can receive e-mails with access requests and can respond to them:

 After navigating to a site/page that a user has no access to, he/she is presented with the following form:

Once they provide the reason, they will see:

When Outgoing e-mail functionality is configured correctly, the admin should receive an e-mail notification with the above access request details and from there, he/she can approve/reject the request or continue the conversation. 

The Incoming and Outgoing e-mail in SharePoint can be configured on a Farm and Web Application level. Web App level overrides settings of the Farm Level.

Very good guides outlining the steps of Incoming and Outgoing e-mail configurations in SharePoint 2010 (applies to 2013 too) are SharePoint Goerge's posts: Incoming e-mail & Outgoing e-mail.

In my organisation, where we have just one SharePoint Server installed on Windows Server 2012 Datacenter, we already had an SMTP Service running. We needed to create Send Connector and Receive Connector on the Exchange Server and apply the settings in Central Admin.

After all the relevant steps were performed, we could start to send e-mails to and from SharePoint 2013 with no issues.

It is all good, like I said- on paper. In our case, the Incoming E-mail settings worked just fine as we used a Virtual SMTP Server (service on our SharePoint WFE), created Exchange Send Connector and enabled Incoming Mail features on the farm level in SharePoint. We could successfully send e-mails and attachments to e-mail enabled SharePoint lists and libraries.
For some reason, the Outgoing E-mail does not work. SharePoint as of then was unable to send alerts for users and SP_Admin did not see access requests to sites sent via e-mail. We had to troubleshoot that...

Having found the resources like:

• Troubleshooting Steps for SharePoint Alert Email Does Not Go Out (add Telnet Client & Telnet Server to the features Windows Server SP2013 is installed on - then you can turn them off)

• Outgoing e-mail service stuck as stopping
• Immediate-alerts Email Notification not sending emails

I learned that there is a certain procedure of troubleshooting Outbound e-mail in Sharepoint.

What I did was to test a connection to my SMTP Server using Telnet. It all went good. I restarted a SharePoint Timer Service on my Windows Server where SharePoint is installed on. I then deleted all the alerts on any libraries and made sure users have properly set up e-mail addresses. I left the system for a night, meaning application pools' would recycle and all the 'housekeeping' would happen over night.

In the morning, I double checked my settings for Outgoing E-mail in SharePoint Central Administration. All seemed to be fine. I logged in as User1 from a client computer and created an alert for one of the libraries. I noticed an immediate e-mail in my inbox confirming successful setup of my alerts:

I knew it is a breakthrough! :)

I then jumped on another machine via RDP, logged in as a System Admin, added a document to the library that the User1 has an alert on, switched back to the User1's machine and BANG! Found something in his inbox:

Remember, it could be lots of issues causing SharePoint to not send outbound e-mails. From not establishing a connection to an SMTP server, database timer locking, firewalls to wrongly configured lists or libraries. 

As usual- stay tuned for more updates of SharePoint 2013 in production!

  

SharePoint 2013 SSL Certificate configuration

I found a great post of Tomas Balkestahl, in which he discusses the steps of configuring SSL and Alternate Access Mapping in SharePoint 2013.

In my scenario, as of now, the SSL is needed to secure a connection to the SharePoint apps that we intend to download from the SharePoint store. We opted for a wildcard certificate since every App generates its own URL that needs to be secured.
We have no Web Application for the apps yet. It will be created at a later stage and there will be no separate domain for the apps too. The business requirement was to secure the main company domain with the wildcard certificate hence we isolate apps in a different Web Application and keep their sites in restricted zone.
[To start with, you could not host your apps on a Web application with Alternate Access Mapping configured. It looks like now, you can! ]

#################################################################################

One of the feature updates of the March 2013 Public Update for SharePoint 2013 enables you to use multiple app domains in SharePoint 2013 environments with alternate access mapping or host-header web application configurations. For more information, seeEnable apps in AAM or host-header environments for SharePoint 2013.

Copyright: Microsoft Corporation

#################################################################################

So, for the time being, we just installed an SSL Certificate on our main Web Application used for portal and configured it to use HTTPS only. The same procedure would have to be repeated with every other Web application we have or we ought to have.

If you follow the steps in the post of Tomas Balkestahl you will be able to find out how to install an SSL Certificate and configure bindings.
In my case, the SSL Certificate was installed for me and the binding were configured as well:

I had to set up AAM in SharePoint 2013 for a given Web Application and configure a local machine to access the HTTPS sites.

Central Administration -> Configure alternate Access Mapping :

#################################################################################

-

5.2 Next thing we want to do, is to alter the existing Public URL so that it uses https instead of http. Since all else is ok, add the s…

5.3 Ok on that will give you this view, note that both the Internal URL and the Public URL has changed. This site is now only accessible by the https protocol. (Not entirely true, but true enough)

5.4 I always like to be able to type in the default http URL in my browser, and if the site uses https, be redirected automatically. This is rather easy to do in SharePoint, simply add an Internal URL using http and add it to the Default zone which will direct us to the Public URL using https. It may sound difficult but trust me, it just works.

If you are interested in Learning more about Alternate Access Mappings and the inner workings, I have a free whitePaper published on the subject for 2010 Here and a basic post for 2013 Here.

Anyways, click on the Add Internal URLs link and simply add the same URL using http, make sure that the default zone is selected.

-

Note: The zones used in AAM has NO RELATION with the zones in Internet Explorer, they are named similar, but they have no connection whatsoever.

5.5 Now the list should look like this, note that you have http and https on the left (incoming traffic) and only https on the right (target):

You are now done configuring your Alternate Access Mappings!

Copyright Tomas Balkestahl

#################################################################################

The above procedure will indeed get HTTPS protocol to work. It will not however automatically redirect HTTP requests to the HTTPS. Instead, users will see HTTP 403 Forbidden error.

Stay tuned to see how I have tackled this!

SharePoint 2013 Document Information Panel causes Office applications to crash

Another day in working on a production SharePoint 2013 for the real company and we have some more issues! As expected!

For some reason, after a successful publish of a content type from my Content Type Hub site collection to a subscribing site collection (see my last blog post), I encountered a strange problem.
Namely, the site column which I created and included in my content type happened to be a Managed Metadata column. After configuring it to be included in a Document Information Panel and upon opening a document form a library, the office applications (Excel, Word...) were crashing. This was happening while the Document Information Panel was trying to load.
For testing purposes, I deleted a Metadata Column from the content type, later deleted content type from the Document Library and documents were opening.

I could not afford to not have a Managed Metadata column in my library therefore I had to find a solution to get it working.

The first, immediate thought that came to my mind was: Because I have MS Office 2010 and SharePoint Designer 2013 installed on my machine, I knew this can cause issues. (You have to use SharePoint Designer 2013 if you are working on SharePoint Server 2013). Both Office 2010 and SharePoint Designer are 32-bit software, otherwise they will not work. I tried to go to:

Control Panel -> Programs and Features -> Click on MS Office 2010 -> Change -> Repair!

You restart the computer and it all works! The Document Information Panel loads in successfully with Managed Metadata Column in it.

Stay tuned for more issues with bloody Sharepoint!    

SharePoint 2013 Content Type Publishing Proxy Error

When you provision one of the Site Collections to be your Content Type Hub for the whole farm so the other site collections (and even Web Applications) can subscribe to it to consume enterprise-wide Content Types- you may encounter an error: 'No valid proxy can be found to do this operation- publishing of content type'

As per the Steve Chen's blog post, this is due to:

a) Wrong URL settings on the managed meta data service application. 
- The content type hub was set on URL http://sp2k10a/sites/CTHUB/SitePages/Home.aspx 
- This URL was also set in the MMS app

b) Missing entry in the AAM’s 
- The MMS web service was listening on address http://hostname:32843/... But in AAM settings we only had a map to http://hostname:4000 which is the CA

The solution to tackle this issue is (depending on where you already are with your scenario) to:

1. In your Content Type Hub site collection- create some site columns you wish to include in a content type;

2. Create a desired Content Type and add newly created column(s);

3. In a newly created Content Type settings, try to publish- received error? Read on...

4. Go to Central Administration -> Application Management -> Manage Service Applications and highlight 'Managed Metadata Service' [top link above Managed Metadata Service Connection]

5. Once highlighted, click 'Properties' on the ribbon and scroll down towards the end of page

6. Input the URL of your Content Type Hub Site Collection making sure you exclude /sites/home.aspx or any other suffix after the domain name.
Make the URL look like http://intranet.domain.com

7. Check 'Report syndication...' and click OK.

8. Being back on the Service Application page, highlight a 'Managed Metadata Service Connection' and click 'Properties' on the ribbon

9. Check the 'Consume Content Types from the Content Type Gallery at...'

10. Go to Central Administration -> Monitoring -> Review Job Definitions;

11. For 'Content Type Hub' and 'Content Type Subscriber' [subscriber for a required Web App], run the jobs immediately to push all of the changes:

12. Now, go back to your Content Type Hub Site Collection and re-attempt to publish a content type in question;

13. No errors? If you still see some error, most likely you need to correct your URL to make sure it has nothing after 'domain.com'.

14. Navigate to any other site collection -> Site Settings -> Site Content Types and verify a newly published content type is there!

Regards

SharePoint 2013 New file cannot be saved to a destination library

When SharePoint site is added to the trusted sites in IE and Trusted Sites' custom level includes 'Automatic logon with current user name and password' (see one of my previous posts), we might have messed up something in SharePoint - Office client association. Or maybe it is a Microsoft's bug on certain clients?
The situation is that when you click on a file already in the library to edit/open it- it opens up nicely in the client application without asking for credentials. Depending on the Library Settings, if you want to edit it, you might Check Out the file. We are fine here.
Similarly, when you Upload a file from your local machine into the Document Library, it is done without any problems (however it will not let you save the file under the name that already exist in the library unless you check to add another version of it). In that case users must ensure they upload files with names already changed!
Our real problem is when we click 'New Document', we are being re-directed to the client application based on the Library template, we create/edit the file, want to save it back to the Library and then - BOOM! Cannot do it! Client application offers to save the file locally and when you click 'Save & Send' to save it to a selected SharePoint Library- you will see a fancy error message 'Cannot save to: http://intranet.company.com' or something like that.

In order to fix that, you have to enable a WebClient service in Windows Services as per this blog post. On my machine (happens to be a Windows Server 2012 Datacenter) it is well hidden and it s called a Desktop Experience, see picture below:

It resolved the problem of not saving a file into the library the request of a new file originated from. Well. partially. Now SharePoint wants to authenticate you before it saves your file!

You remember we added our intranet to the trusted sites (you can leave in your intranet zone, whatever- it is after all a browser, not SharePoint configuration. The best way is to have a play and see which configuration- Intranet Zone or Trusted Sites works best). But why MS Office applications installed locally want credentials to upload files back to SharePoint? Microsoft says- "it is our fault" on Vista and 7 and they provide a hotfix.

In short, you have to add a registry value to your local registry (on a machine with Office Applications installed through which you are accessing SharePoint sites). Perform:

#################################################################################

1. Click Start, type regedit in the Start Search box, and then press ENTER.
2. Locate and then click the following registry subkey:
   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters
3. On the Edit menu, point to New, and then click Multi-String Value.
4. Type AuthForwardServerList, and then press ENTER.
5. On the Edit menu, click Modify.
6. In the Value data box, type the URL of the server that hosts the Web share, and then click OK.
   
   Note You can also type a list of URLs in the Value data box. For more information, see the "Sample URL list" section in this article.
7. Exit Registry Editor.

After this registry entry is created, the WebClient service will read the entry value. If the client computer tries to access a URL that matches any of the expressions in the list, the user credential will be sent successfully to authenticate the user, even if no proxy is configured.

Note You have to restart the WebClient service after you modify the registry.

Sample URL list

The following is a sample URL list:

https://*.Contoso.com
http://*.dns.live.com
*.microsoft.com
https://172.169.4.6

This URL list enables the WebClient service to send credentials through the following channels.

Copyright Microsoft Corporation

#################################################################################

You can use your Group Policy to apply the fix and add your intranet website to trusted sites in IE.

Stay tuned for new updates in SharePoint 2013 in production!  

 

SharePoint 2013 Navigation options

Ok, the time has come to provide some global navigation links to the users of our pilot site.

The immediate thought is to use Metadata Navigation- one of the great features in SP2013 (ease of use, ease of management and consistency). 

Unfortunately, in my scenario, not every user will have read access to every site/page/library in my site collection. Managed Metadata Navigation- as of 18/07/2013 does not provide security trimming! What is the point of users being able to see links to resources they cannot see? When they click on one of the links they do not have right to access, they will see an 'Access denied aspx'. I have a strange feeling that they will not like this.

According to one saying: 'Out of sight, out of mind'- we will have to stick to hard-coding our links in headers in Site Settings -> Navigation (in order to see this link in Site Settings you have to activate Publishing Infrastructure Features both in Site collection and site levels):

Unlike with using Metadata Navigation (up to 3-tier dynamic menu allowed), we will be limited to Headers (links of their own) and Links below them (2-tier dynamic menu):

SharePoint 2013 Disable Prompts for User Credentials when opening Office files

Probably most of us have experienced this! Very annoying!

The solution is to:

IE -> Tools -> Internet Options -> Security Tab -> Click on 'Local Intranet' -> Sites -> Make sure that 'Automatically detect intranet network' is checked.

Now switch to 'Trusted sites' -> Sites -> add your intranet site [if having one web application like me, just add the domain root e.g. http://intranet.company.com].
Staying in 'Trusted sites', click on 'Custom level...', scroll down to the bottom and check 'Automatic logon with current user name and password' as in picture below:

Annoying pop-ups for user credentials should no longer be coming up!

SharePoint 2013 Hiding Site Collection Home Tabs

If you have a Site collection's logo in a top left hand corner, it works as a link to the Home Page.
Further, if you require a number of links to other sites in your top navigation menu, you could actually do with hiding this name tab menu so you have more room for adding links to the top navigation bar.

As per suggestions as well as due to my previous experience with SP2010 Server, I tried to edit a core CSS file by adding the following code to it. 

.s4-tn li.static $gt; a{
display: none !important;
}
.s4-tn li.static $gt; ul a{
display: block !important;
}

It worked like a charm in SP2010. In SP2013 it did not for me!
So I injected a following javascript into the page in Content Editor Web Part:

-where 'UK Accounts' was used instead of 'Home' as it is the name of my first home tab to hide. This approach is just looking for a text on the page and it hides it. You probably gather, it has some disadvantages too.

As you can see in the picture above, the phrase/name we are hiding on a page is also removed from Titles of web parts (e.g. Calendar), subjects names of the discussion posts (note a doted red line where 'UK Accounts' is present in the main body of a post- just the subject title is removed).

Overall, it is not very good approach don't you think? Especially when the phrase 'UK Accounts' may be used for other objects available on that page.

Going back to the original naming in SharePoint, the word 'Home' sounds like an appropriate word to be used for hiding a root site tab. I do not think users and admins will use this word to refer to any of their work.

So I changed the name of the home page to 'Home', then I modified my javascript to include 'Home' instead of 'UK Accounts'.

This is the result:

Part of the site collection logo contains a reference to the actual site collection so users will always know they are on the 'UK Accounts' pages.

When you dive deeper into the Site Collection pages, respective sites' root pages names would have to stay unchanged. They can no longer  be changed to 'Home' because users would again see UK Accounts - Home as opposed to UK Accounts - UK Budget for example on a Logo-Page title level.

   

Just in case, I posted in an MS SharePoint forum to ask whether there is someone out there willing to help explaining the CSS route as opposed to Javascript for hiding a home tab in SP2013. I also highlighted disadvantages of using javascript in my scenario. Read my comment to the first reply in the thread.

SharePoint Server 2013 Blob Cache

According to another very good practice when dealing with SharePoint Server 2013, I increased the size of a BlobCache in every web application and moved the BlobCache file outside the system drive.

In our case, we created an E:\ drive on which we stored our IIS, ULS and Usage logs as well as the Search Index to further ease-off the pressure from C:\.

I also created a 'BlobCache' folder and subdirectories for each web application in the farm, including Central Administration.

 
Then, I navigated to the web.config file of each web application, and opened it with Notepad.
In each file I pointed to the new directory created and increased the BlobCache size from 10 (GB) to the amount required:

As a side note: I noticed that 'Automatic Updates' were turned off for our Windows 2012 DataCenter.
I turned this on:

Stay tuned for more Sharepoint 2013 in real company!

SharePoint 2013 in production- wake-up scripts.

I continue to blog about what I am doing and how I am configuring SharePoint Server 2013 in our real world company.

I think everybody knows that according to Windows Server 2012 default behaviour, all the application pools will recycle overnight. You can obviously tweak these setting but I think it is still a good practice to let the application pools recycle- weather based on fixed time intervals, memory or specific time.

This will have significant impact on how fast the SharePoint Server 2013 pages will load up first thing in the morning.
Since we operate in the UK and US (6 hours difference) and our system must be responsive more or less 24/7, we still had to think about a good time to let our pools recycle. We decided that 4 am UK time (10 pm US time) would be satisfactory, so I set that up in the IIS Manager.

A very good and neat script provided by Todd Klindt takes advantage of the new features in PowerShell v3 in SharePoint 2013 and takes warming-up SharePoint to just two lines of code:

Get-SPWebApplication -IncludeCentralAdministration | ForEach-Object { Invoke-WebRequest $_.url -UseDefaultCredentials -UseBasicParsing }

In this example, Central Admin web application gets warmed up too.

Make sure you have a site collection in every Web Application otherwise the script will spit out some errors like in my case. It seemed to wake up the remaining Web Application (already populated with site collections) but my comparison results were not spectacular. Because I do not like red colour in my PowerShell window and I wanted to have an absolute certainty that this in fact works, I quickly created a host site collection in my MySite web application and the script ran OK. Now the users have a platform to create their personal sites (for which I also set up a quota of 2048MB) and take advantage of social features in SharePoint Server 2013. 'Quickly', because I have not finished provisioning of User Profiles Service Application as the process is complex and require a list of people from AD to which I do not have access yet.
[See details of how to accomplish this and step-by-step guide here. In addition, if you want other site collections in other web applications to be able to consume a User Profile Service Application used in My Site (enterprise wide social features e.g. hashtags), you have to connect each web application to that User Profile Service Application: see TechNet article outlining this].

My script to warm-up Sharepoint Server 2013 should run with no errors. It ran. Once. Then I was getting this annoying error after recycling my web applications again to further test the script:

Invoke-WebRequest : The remote server returned an error: (500) Internal Server
Error.
At line:1 char:41
+ Get-SPWebApplication | ForEach-Object { Invoke-WebRequest $_.url
-UseDefaultCred ...

I knew it is due to MySite web application that caused problems from the very start of our SharePoint 2013 installation.  When navigating to the root site of this site collection in the browser- unexpected errors occurred so it must have caused more harm than good when running our script.
I deleted the My site host site collection because it was giving me more errors like 401 Unauthorised, 500 Internal Server Error.

I came back in the morning after pools have recycled, re-ran the script and I got this:

Invoke-WebRequest : HTTP/1.1 200 OK Server: Microsoft-IIS/8.0 Date: Fri, 05
Jul 2013 07:46:00 GMT Connection: close
At line:1 char:41
+ Get-SPWebApplication | ForEach-Object { Invoke-WebRequest $_.url
-UseDefaultCred ...
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:Htt
   pWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShe
   ll.Commands.InvokeWebRequestCommand

The issue is currently with Todd Klindt on his blog. Maybe he can shed some light on what is actually wrong with the script and my configuration.

Just you know what are we even fighting for, here are some test results showing you how slow and how fast SharePoint Server 2013 can be when it is needed by e.g. most important people in the organisation.
Note: the results are not accurate to the every millisecond. Times are taken using a Stopwatch on the phone but are still very indicative.

Time needed to access 'cold' SharePoint 2013 root site after successful login:

Time needed to access 'warmed-up' SharePoint 20013 root site after successful login:

I think we all see that the matter is worth pursuing.

Since the script is not running 100% OK in our case, I will keep you updated on any fixing activities I may do (hopefully with some help from Todd Klindt).

EDITION- 30 JAN 2014

Finally got a working script here: SPWakeUp. You might want to run it as SP_Farm. I tried with an SP_Admin (daily administration of SharePoint) but it spat out couple of irrelevant, but annoying errors.

Schedule it with Task scheduler to tickle SharePoint sites in the morning and maybe every 15-20 minutes before pages go to sleep ;). Good luck.

SharePoint 2013 post installation configuration

Upon opening of Central Administration, we are immediately presented with some issues highlighted in the yellow bar above the links:

After a short internet research, it is clear that some of these issues are encountered due to the use of the AutoInstaller.

One of them is a configuration error resulting in 'Missing server side dependencies.'- see below:

The issue is caused by misconfiguration of a Search Service Application and it is fixed by navigating to the actual 'Search Administration page'. If like me, you received the following error:

- you have to just do what they say and go to the Central Admin and browse to Manage Service Applications. In there, you will find a link highlighted in red that you need to click to go to that page:

Another step required to eliminate 'Missing server side dependencies' error is to navigate to the Search Farm Dashboard page in the format: http:///SearchFarmDashBoard.aspx like in the picture below:

This time, we are able to display the page with no issues or requirement to open this page through Service Application links in Central Admin.
Now, we simply re-analyse the issue of 'Missing server side dependencies' to find out that the error is gone:

OK, there were other problems as you can see but for the time being, I will just ignore them and continue working on the system.

My plan was to have a one 'Portal' web application that will host managed path site collections for the respective departments in our company. That includes UK and US site collections. I was not separating them in different web applications. For reasons why I did that, just search Google for 'web application versus site collection'.
Second web application 'MySite Host' will not be used at the moment since there is no requirement for users' personal site collections. To be honest I was a bit surprised as to why this web application installed itself in the first place. This web app caused an error in one of the Autoinstaller scripts and we decided to get rid of it during our provision of an XML for SharePoint installation.
Anyway, it is there and it has no site collections yet. I might need it in the future.
Third web application was obviously a 'Cenral Administration'.

So ,what I actually had was a site collection created at the root attached to the database called 'SP_Content_Portal'.
Then, I planned to create some site collections but in their own content databases and with their explicit managed paths. The order was:

1. Create a first bunch of content databases using Central Admin
2. Stop all of them except the one I wanted to use with my new site collection I was about to create (Accounts UK in this example):

    3.   Create a new site collection using Central Admin:

   4.   On a 'Create Site Collection' page click 'Define Managed Path' link highlighted here in red:

   5.   Create a new managed path, in my case: /uk_accounts and make it Explicit if you do not want any
         new site collections to be created below that managed path. You can use a Wildcard if you do want
         that.

   6.   Now, on the 'Create Site Collection' page, refresh the page by pressing F5 and pick a newly created
         managed path. In my case it was /uk_accounts. In the picture below you will see /us_engineers as the
         screen was taken a bit later in the process.

   7.   After creating this site collection, it was automatically added to the database that was 'Started' at the
         time. You remember we stopped every database except 'SP_Content_AccountsUK'

You basically need to repeat the process with every new site collection and content database. So to re-cap, you:

• create a content database with a meaningful name and in a consistent naming convention
• stop every content database except the one you just created and want to attach to a new site collection
• navigate to Central Admin and click create a new site collection
• on that page click 'Define Managed Paths'
• add meaningful, consistent path and come back to 'Create Site Collection' page
• refresh the page and pick the newly created managed path
• finish creating a site collection
• enjoy having a site collection in the database you want

Today, I created 4 additional content databases and attached each of the newly created site collection to a corresponding content database. Every site collection has a meaningful and explicit managed path. I ended up with 5 site collection all together in a 'Portal' web application.
I know, I know! You say PowerShell! Well, I will leave PowerShell in peace for the minute. I am sure I will need it later...

  

Having done the above, I moved to the general configuration of the farm, going through the functions I wanted to implement. Stay tuned for updates of what has actually happened!