I recently ran into an issue with a customer in a multi-server SharePoint farm (1 SQL server, 1 WFE, 1 APP server), where applying an Enterprise license was not going as easily as it should.  Under normal circumstances, when you have a SharePoint server that is presently licensed for the “Standard feature set”, upgrading to Enterprise is as simple as going into Central Admin, and under “Upgrade and Migration” choosing “Enable Enterprise Features”.

Unfortunately, on this customer, I was encountering the following issue (found in the event logs).

Failed to upgrade SharePoint Products.

An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException was thrown. Additional exception information: An update conflict has occurred, and you must re-try this action. The object SPUpgradeSession Name=xxxxxxxxxxxxxxxxxxx was updated by domain\user, in the PSCONFIG (10056) process, on machine SERVER. View the tracing log for more information about the conflict.

Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SPUpgradeSession Name=xxxxxxxxxxxxxxxxxxx was updated by domain\user, in the PSCONFIG (10056) process, on machine SERVER. View the tracing log for more information about the conflict.

Which is similar to the issue reported in this blog post.

The first thing I tried to do was simply run the Products Configuration Wizard on each server.  The result of which was a successful run on each server, but after retrying the upgrade, it still failed with the same message above.

After much (more) pain, once I finally came across the above blog post, it had several good suggestions.  The first (and simplest – should work most of the time) was to clear the SharePoint Timer Cache.  To do this, follow this other blog post of mine.  Unfortunately, that didn’t solve my problem (or theirs either).  They made other suggestions, which I investigated, but they ultimately weren’t successful either.

Solution

However, as suggested in that same blog post (above), I did go ahead and try to update the CU of the farm.  Once I did that, the farm came completely back into alignment with itself, and I was finally able to upgrade the farm to the Enterprise license (and then apply the Enterprise features as well). 

Let’s say you’d like to create a custom list that had a calendar view associated with it.  And in that list, you wanted to emulate what the SharePoint calendar list does (which is to pre-calculate the End Date / End Time for you).  How does one do such a thing?

Basically, I’m referring to how to calculate the below field. 

Note that to get the Start Date / Start Time, SharePoint will actually do this for you, by selecting “Today’s Date”.

End date (or end time) is the more complicated one.  Here’s the SP formula for calculating it.

=Today+(ROUNDUP(NOW.TIME()*24,0)/24)+(1/24)

Basically, this equates to:

Today (if you don’t include this, your date starts back in 1899), plus the time right now rounded up to the next hour (the middle funkiness), plus an extra hour (1/24).

Now you no longer need the SP Calendar list to do this for you, especially if you don’t want all the integration points that come with the SP Calendar list.

I’m grabbing most of this content from the following link, http://latenightsp.wordpress.com/2011/03/16/sharepoint-config-cache/, just in case the blog disappears at some point in the future – I don’t want this information to get lost.  So many thanks to Mayank Malik over at Late Night SharePoint.

Reblogged from Late Night SharePoint

1. What is the SharePoint Configuration Cache?
   The cache has many names – system cache, SharePoint cache, configuration cache, the cache, that folder with XML files,… you get the drift. It really is a cache of farm’s configuration objects. There is a timer job called “Config Refresh” that updates the cache on SharePoint servers in the farm. Like any other cache, config cache becomes stale over time. Therefore, clearing the cache is needed to get all the SharePoint servers up to date on the latest farm information.
2. How to clear the SharePoint Configuration Cache?
   a)     Stop the SharePoint 2010 Timer service on ALL of SharePoint servers in the farm.
   b)     Log into your Index server.
   c)     Navigate to the directory: C:\ProgramData\Microsoft\SharePoint\Config\GUID.
   d)     Delete all the XML files from the directory.
   CAUTION: DELETE ONLY THE .XML FILES, NOT THE .INI FILE. IF YOU DELETED THE .INI file, see item 3.
   e)     Open the cache.ini with Notepad and reset the number to 1. Save and close the file.
   f)      Start the SharePoint 2010 Timer service on the Index server and wait for XML files to reappear in the directory.
   g)     After you see XML files appearing, repeat steps c, d & e on each query server (one server at a  time).
   h)     After all of the query servers have all been cleared, repeat steps c, d & e on each of the WFE and application servers in the farm (one server at a time).
3. I deleted the entire configuration cache directory. Now What?
   a)     To recreate the directory, you need to know the directory name (which is a GUID). You can find this GUID in the registry entry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\14\Secure\ConfigDB. Copy the GUID from Id attribute and create the new directory: C:\ProgramData\Microsoft\SharePoint\Config\GUID.
   b)     In the directory you just created, create another file called cache.INI. Open the file using Notepad and enter the number “1″ without the quotes. Save and close the file.
   c)     Start the SharePoint 2010 Timer service on the Index server and wait for XML files to reappear in the directory.

I especially like #3, because I’ve [shamefully] done that before, and now I know how to fix it. 

As a holder of a Windows Phone 8, this pleases me, and maybe we’ll finally start to get some notice from the missing app makers out there.

http://tech.fortune.cnn.com/2013/05/16/windows-phone-surpasses-blackberry-for-third-place-in-smartphone-shipments/?hpt=hp_t3

Being a Windows Phoneite, Phoner… Phonee?  As well as a SharePointer…? (English is hard)  I’m a big fan of anything that integrate the two of them together.  I came across a number of recently created SharePoint apps written specifically for Windows Phone 8.  In the link below, you’ll find the blog of the author who wrote the apps, and a description of each.

http://havivi.blogspot.nl/2013/05/five-sharepoint-apps-for-windows-phone.html

I’ve tried them with an account I have on Office 365, and they work just as expected.  They’re also designed to work with on premise deployments, so long as you allow Basic Authentication (which you may not be willing to accept as a risk). 

These Apps make me happy, I hope they do for you too.

What

SharePoint 2013 introduced the concept of 3^rd party Apps, which can be remotely added to your SharePoint farm (via the Microsoft SharePoint Store). In order to set this up, an administrator needs to configure SharePoint and their organization’s network settings to allow this integration between their SharePoint farm and the App Store.

There are a couple possible approaches to opening up your SharePoint farm to connect to the Microsoft App store, each with their own set of pros and cons. The two approaches we’re referring to are as follows.

For the examples below, assume your SharePoint 2013 farm is hosted on the domain “itgroove.com”.

1. Use a unique domain name to host your apps.

   Ex. itgrooveapps.com

2. Use a subdomain (on the same domain as your SharePoint farm) to host your apps.

   Ex. apps.itgroove.com

So What

Microsoft best practices dictate that you should always choose approach #1, and not choose approach #2 (reference), as #2 poses a security risk. The rationale is that by going with approach #2, you’re opening up your farm to potentially malicious code, from a 3^rd party developer. I won’t go into the specifics about how they might accomplish this using approach #2, but to say the least, they’re absolutely correct in their assertion.

There is however a downside to approach #1, which some companies may be willing to accept (the Risk), in order to still allow themselves access to the overall benefit of using the SharePoint App Store. By going with approach #1, you will require an additional external IP address, external domain, and an additional SSL certificate if you plan to expose SharePoint to the Internet, all of which will cost an organization money at an OPEX (operating expenditure) level. Some organizations may not be willing to incur the additional (monthly/yearly) costs, and thus will choose to go with approach #2, in order to avoid said costs, which may be in the range of several hundred to upwards of over a thousand dollars per year, depending on the provider(s).

Now What

itgroove’s recommendation is to always follow Microsoft’s best practices, and use a separate, unique domain for your SharePoint apps. Given that statement, we’re aware that not every organization will be willing or able to afford the additional costs – so it comes down to accepting the risk or paying for the domain and management to mitigate it.

Depending on your organization’s needs, you may choose to accept the additional security risk, in order to save the additional OPEX cost.

There are several tools out there which help you build mind maps, but the nice thing about this one is that it’s integrated right into your Word documents, PowerPoint, etc.  It does cost a nominal $2.99, so it’s not free, but it does come with a free trial, so you ultimately have nothing to lose.

If you’ve never tried mind maps, they’re a great way to throw out a bunch of ideas (which tend to spawn other ideas, and so on and so forth).  I recommend you check it out.

http://office.microsoft.com/en-us/store/mindmapper-WA103953725.aspx?

Yes, you heard right.  It’s all covered in this post here, http://news.cnet.com/8301-10805_3-57582017-75/microsoft-frames-skype-in-outlook.com-inboxes/.  There’s a good video in the article (corny – sure, but it helps to show off the premise).

Be a beta tester, and make Facebook for Windows Phone be all that it can be.

http://blogs.windows.com/windows_phone/b/windowsphone/archive/2013/04/30/join-the-facebook-for-windows-phone-beta-app-program.aspx

I recently got Access Services (2013) in place in our internal SharePoint 2013 environment.  The following is what I learned from trying to go through this install (for the second time — the first time was a failure because we hadn’t setup Apps properly).

NOTE: In this article, unless otherwise stated, all references to Access Services apply to Access Services (2013) in SharePoint Server 2013.

Hardware / Software

• SharePoint 2013 with a WFE Server and an APP server (in our case, these were different virtual machines) on minimally Win Server 2008 R2, preferably Win Server 2012
• SQL Server 2012 SP1 Server (minimally, you need “Standard”, “BI” or “Enterprise” also work) – SQL Server 2008 is NOT sufficient for Access Services 2013

Details

• Download this document, which is from MS and is the starting point for documentation.  http://www.microsoft.com/en-us/download/details.aspx?id=30445
  • Follow the steps in the document, I’ll just summarize things a bit below, and my experience.
• You’ll need to download the following components (to your SharePoint “APP” server).
  • Microsoft SQL Server 2012 Local DB (SQLLocalDB.msi)
  • Microsoft SQL Server 2012 Data-Tier Application Framework (Dacframework.msi)
  • Microsoft SQL Server 2012 Native Client (sqlncli.msi)
  • Microsoft SQL Server 2012 Transact-SQL ScriptDom (SQLDOM.MSI)
  • Microsoft System CLR Types for Microsoft SQL Server 2012 (SQLSysClrTypes.msi)

These are available from the SQL Server 2012 Feature Pack.

• You’ll need a desktop/non-SP server machine with the Access 2013 Client application installed (must be Office 2013, and should be Professional Plus) for the very last step
• You need a SharePoint farm built to best practices
• You MUST first configure your SharePoint environment (completely) for “apps” – without this, the rest will fail.  Check out this TechNet article for details.
• Create a new instance on your SQL server 2012 for ACCESS.  Typically you can use the same server as is running your SharePoint DBs, this instance isn’t likely to be overly taxing – unless your Access DBs are ridiculously large.
  • Ensure you setup backups for this instance in your backup software
• Setup the SQL server according to the settings in the installation document (above).
  • Including the database instance, security mode, specific settings (triggers, language, etc.)
• Setup the firewall on the SQL server appropriately (if you have a separate instance, running on a different port, be sure to open that port in the firewall)
• Install the SQL server components (you downloaded above) on your APP server (they shouldn’t need to be installed on a WFE, only the server you plan to run Access Services from – which should be your APP server).
• Now go into “Manage Services on Server” under “System Settings” and enable the following services (on your APP server)
  • Secure Store Service
  • Access Services
  • Access Services 2010 (yes, you really should set this up too – like it or not)
  • App Management Service
  • Microsoft SharePoint Foundation Subscription Settings Service
• From Central Admin, run the farm configuration wizard and turn on the required services (as noted in the last step)
• Now go back to earlier in the document and setup the “IIS Application Pool Load User Profile Setting”
• Ensure you have a security key setup in your secure store
• Create a site collection that you’ll use as your “Access apps management store”
  • Once created, go into the site collection and ensure you setup permissions for everyone who will need permissions to create access apps – in order to create an access app, you’ll need at least “Owner” level permissions.
• Go back to Central Admin and setup a “New Application Database Server” (under the Access Services 2013 service in “Manage Service Applications”), point it at the ACCESS instance you setup earlier (I recommend you use a SQL alias to do this)
• Finally, create a new Access App from Access 2013, and point the “web location” to the site you created earlier
  • Don’t forget, in order to be able to create an App, you need Owner level permissions