This is a sad and dark day for the Microsoft community, especially for us who love products such as SQL Server, Exchange, Lync and SharePoint. Microsoft Learning (MSL) has decided till kill their advanced certifications; Microsoft Certified Architect (MCA) and Microsoft Certified Solutions Master (MCSM) formerly known as Microsoft Certified Master (MCM). This is also a post I hoped not to write, as the matter of fact I started drafting a post a couple of weeks back that should recommend these certifications to the community out there, that post will never see the light now.
Breaking up with an e-mail!
This morning I and the whole MCA/MCSM/MCM community got an e-mail from Microsoft Learning stating that “we [MSL] are continuing to evolve the Microsoft certification program” but “[MSL] will no longer offer Masters and Architect level training rotations and will be retiring the Masters level certification exams as of October 1, 2013”. This e-mail came as a shock to me, and as it seems to all involved, including instructors. All already certified will retain their certification status and can still use the logo (well, thank you very much), and those in rotation or with scheduled exams have barely one month to get it or get just a small amount of refund! This is truly a slap in the face for everyone! Also sending this e-mail out on a weekend with a US holiday coming up, just to try to get under the radar is a cowardice action – and just shows how not thought through and quick the decision has been made.
Why are MSL retiring the advanced certifications?
Well, that is one question that I would like to have answered. In the rather offensive e-mail sent the following was stated: “The IT industry is changing rapidly and we will continue to evaluate the certification and training needs of the industry…”. Doh! We know it is changing, but that definitely doesn’t mean there is less requirement on training and certifications, especially these advanced certifications! About one year ago the MCM certification was changed into MCSM that took this new “era” of cloud into the curriculum. For those who have attended the last updated training know this. We’re talking a lot about Office 365, Azure etc. during the training and exams.
I think Microsoft has to much belief in the cloud – that it will change over night – it won’t. The vast majority of SharePoint installations are on-premises today. Even if we/you see a cloud only future, there is a long way to go, and that road required skilled professionals staking out the route. And just because Office 365 satisfies the most common scenarios it will never be in parity with the requirement of Enterprise solutions. And Lync, SharePoint, Exchange and SQL are each on its own still a billion+ dollar segment for Microsoft.
Today I’ve seen a couple of blog posts and tweetface posts from people who hasn’t attended any of the rotations. These persons claim to know why MSL is retiring the certifications with reasons such as 1) we’re on a way to a cloud-only world, 2) the program costs Microsoft to much money, 3) there’s no demand for these certified masters etc. Oh boy, they have no clue! One thing I can agree upon is that MSL have done a really bad job in marketing the advanced certifications – most of the marketing has been done by the attendees! Another reason stated is that it was written in the stars – well, all parties will eventually end, but this is not how to end it, punching their most dedicated fans in the balls!
I’m still waiting for a decent reason from MSL…
Why do I think the MCA/MCSM should remain?
Noone except those who actually attended the rotations (which is what we call the training, which was required to get certified) really knows how valuable the certification is. Or to be more precise the certification in itself doesn’t mean that much – the training and the community is what matters. The Master certification has increased the SharePoint knowledge and expertise since the dawn of the certification, in the whole community. The blog posts, conference sessions, webcasts, books etc written by Masters would not have been as good if they didn’t attend the training, and eventually achieved the certification. This is a big loss for all of us, with no new training and no new fresh blood in this group we’re looking into a darker future.
Ok, what about the MVP’s then you think! Well, an MVP is award, not a certification. I have been awarded the MVP award, but not for my knowledge – it’s all about visibility and connections. I’m still proud of being awarded and thankful for what it gives me. But the MCA, MCSM and MCM means much more to me (even though the benefits are way less than for an MVP and you have to pay big bucks for it). You can ask any of my customers and my employer and they will tell you how much I and they have benefited from these certifications. But the “new Microsoft” doesn’t care about its customers as I see it…
I’m very proud and thankful to have learned as much from the amazing instructors and my fellow masters. There will be no more Certified Masters or Certified Architects or recertified Certified Solution Masters…
I could have written a way longer post on this subject, but this is the end of this road. What it actually means in a bigger perspective is another question for another day – but I do know that it will influence my future considerations and investments in certifications and the products that I used to love.
I’ll try to share some updates on the matter here…
[2013-09-01] A fellow MVP from the SQL charter, Jen Stirrup, has created a plea on the Microsoft Connect site (currently 213 upvotes!). The one who claims to be responsible for the decision, Tim Sneath, has answered. His answer contains some of what should originally been communicated. But, stating this has been in the plans for months – I don’t believe it, why would MSL then have spent all the time on making the certifications available on Prometric centers, B**sh!t
Overview and background
This post is intended to show and explain why you see the intermittent (and annoying) “To start seeing previews, please log on by opening the document.” message when using previews from Office Web Apps Server 2013 (WAC) with SharePoint 2013. Unfortunately I do not have the magic bullet (yet) on how to solve it completely, this post is more on why you get it and how you can avoid seeing it too often.
SharePoint 2013 allows you to view and edit Office documents in the browser using the Office Web Apps Server 2013. You also have the benefit that you can see previews of these documents in for instance Document Libraries and Search Results. Sometimes, in some farms more than others, the end users get a message that says “To start seeing previews, please log on by opening the document.”. Most often you resolve the issue by clicking on the link in the message – but this is not a waterproof solution.
Why this message?
First of all I need to say – the message have nothing to do with Office Web Apps Server 2013, it’s a SharePoint 2013 implementation issue, and there are two major reasons why this can happen. The message can only happen in these previews (InteractivePreview in WOPI speak) – and if you pay extra attention to the link in the message you will see that the link takes you to another display mode – the view mode (View in WOPI).
This is the URL that shows the message:
This is the URL in the link:
Anonymous Access enabled on the Web Application
The first reason for this to happen is when you have enable Anonymous Access on the Web Application that hosts the document AND that the current site has not enabled any anonymous access (AnonymousState on the SPWeb is set to Disabled) . This is a hardcoded setting and you cannot work around it. I don’t have the whole background to it, but I do think it’s a security measure to prohibit anonymous users accessing content they should not have access to. One of the reasons behind this thinking is that the WopiFrame.aspx page is actually inheriting from the UnsecuredLayoutsPageBase – a specific class used for Layout/Application pages that does not need any authentication. This of course is a requirement if you would like to show previews on an anonymous site. Unfortunately this issue hits you if you have the need to have something partly anonymous and partly authenticated such as in an extranet.
The user is not authenticated!
The second, and by far most common, issue is that the message very randomly appears. SharePoint 2013 has hardcoded the logic, so that if you are not authenticated you should of course see this message – nothing wrong with that. The problem is that we’re using the WopiFrame.aspx page – which can accept anonymous requests.
Since we’re using Claims Mode authentication for the Web Application (a requirement for WAC) the end users will eventually be un-authenticated when their tokens time out and they need to re-authenticate. The WopiFrame.aspx will not do that for us – it will just say sorry you’re anonymous and show the message.
Note: A non functional Distributed Cache or not using session affinity can make this problem worse, making the message appear more frequently.
And now we come to something that I find very peculiar. There is actually another layouts page – the WopiFrame2.aspx file. This one inherits from the LayoutsPageBase which will force us to authenticate and at least check that the user has view and open permissions on the site. This page is not used at all (except in one specific case where the user is not authenticated as above, we’re in interactive preview mode, there is no HTTP context and/or some other crazy stuff – basically you’re not hitting it).
It’s not much we can do about this either – I think it is partly a logic problem in the SharePoint code base and partly a result of the nature of Claims authentication.
Unfortunately there is not much we can do about this problem at present, and I do hope that something with that logic could be improved in future releases of SharePoint (I tested it with 2013 June CU this time). The best option would be to always use WopiFrame2.aspx when Anonymous Access is not enabled – but that is just my thought…
If anyone on the SharePoint Team responsible for the WOPI stuff could chime in I would appreciate it.
For the fifth (if I recall correctly) year in a row I’m proud to present that I will speak at the annual SharePoint and Exchange Forum 2013 conference, September 30th to October 2nd. This year Office 365 MVP Göran Husman not only managed to bring some of the top-notch speakers around SharePoint, Exchange, Lync and Office 365 to the conference, he also convinced them all to dress up in sailor suits and have the conference on a cruise ship between Stockholm, Sweden and Helsinki, Finland.
If you’re around and are in for a real adventure you should book your cabin (which are limited) on this cruise and learn from the best in the business. You will also have the great opportunity to see one of the largest and most beautiful archipelagos in the world:
Personally I will present my Real world SharePoint 2013 architecture decisions session which will take you through a lot of the architectural decisions, not always mentioned on TechNet, you have to take when implementing a SharePoint 2010 or SharePoint 2013 solution.
Bring your life vests…
I frequently see one specific question asked on distribution lists, Twitter, Yammer and other social networks: “How do I install Office Web Apps 2013 (WAC) on the same machine as SharePoint 2013”, very frequently also followed by “any hacks accepted”. Those who have tried have noticed that there is a hard block – SharePoint cannot be installed on an Office Web Apps machine and Office Web Apps cannot be installed on a SharePoint machine. This is purely by design and I will in this post show you why and why you shouldn’t try to hack it.
Office Web Apps 2013 owns IIS on the machines where it is installed
The heading says it all – on the machine where Office Web Apps 2013 is installed the IIS (Internet Information Services) is very much controlled by WAC. WAC creates two Websites (see image to the right) and numerous Application Pools in IIS. In order to be in good condition, and avoid people fiddling with it, WAC will actually recreate the Websites and Application Pools whenever it boots or the WAC service is restarted. One more time – WAC removes the Websites and Application Pools and creates new ones every time the machine is booted or the WAC service is restarted (Restart-Service WACSM).
The recreation of the Application Pools also prohibits any hacks to change the accounts of the Application Pools for Office Web Apps – something you never ever should do, it’s not supported and it is a security risk.
The HTTP80 Website is the one that is used for all the WAC stuff (viewing, editing etc). Depending on your configuration that one is configured to listen on port 80 or 443 – for all IP addresses on the box. The other website, HTTP809, is the administration website using port 809 and 810 to synchronize settings within the farm. As you can see the HTTP80 Website will very much likely collide with a SharePoint Web Application (and any other Website for that matter). As you (might) know with SharePoint 2013, Apps and Host Named Site Collections we want a Web Application, without host header listening on port 80 or 443. There’s a collision right there. If we managed to get SharePoint installed on the WAC machine and try to fool WAC to use a host header, that would just be reset for every reboot or restart of the WAC service and our IIS Website would be removed for the SharePoint Web Application.
What if I add another Website/Web Application and uses host headers?
So you think you are smart now! What if you added a SharePoint Web Application, without host headers, and then go in and modify the bindings in IIS. Could work in a development environment, but never a good approach in production! Unfortunately this dog won’t hunt either. When you restart the WAC service it will actually not only remove the WAC Websites but also any IIS Website listening on port 80 or 443. Try it – just add a Website on port 80 in IIS, host header or no host headers, dedicated IP or not etc and restart the WACSM service – they will be removed. The only Websites that will remain in IIS are the ones created on ports other than 80, 443, 809 or 810.
I hope that this little blog post helped you explain why you cannot have both Office Web Apps 2013 and SharePoint 2013 or any other IIS application on the same machine. There’s no hack and there should not be one. If you ever get asked that question again – just send them here.
I’m proud to announce that I will be speaking at TechEd in New Zealand the 10-13th of September. This is really cool and my first trip down to Kiwi land. TechEd is a conference for all Microsoft technologies, not only SharePoint, but the lineup of SharePoint speakers and sessions at this conference just looks awesome; Dr. Search aka Neil Hodgkinson, MCA Wayne Ewington, MVP Mark Rhodes, MVP Debbie Ireland amongst others. If you live in the southern hemisphere and are just remotely interested in SharePoint you need to get your ticket ASAP!
I’m presenting a total of three sessions at #TENZ…
Real world SharePoint 2013 architecture decisions
[SE307] SharePoint 2013 is still a new kid on the block in the enterprises and even though large portions of the architecture is similar to SharePoint 2010 there are some tough choices to be made by a SharePoint architect. SharePoint 2013 is requiring more resources, have new and improved topology options – how does those affect our design decisions? The Distributed Cache and the new Search architecture are two important features and how do we factor those into the architecture equation? And what about Apps in the on-premises installations? In this session we will discuss all of these and more and take a look at our options, based on real world implementation experience.
Mastering Office Web Apps Server 2013 operations
[SE313] This session will cover from A-Z how to setup, configure, patch and maintain your Office Web Apps Server 2013 farm. Through an extensive set of demos we’re going to set up a new Office Web Apps Farm, configure it for high-availability, going through security considerations and finally connect the Office Web Apps Server to SharePoint and Exchange.
Looking forward to see you all down there…
This is a follow-up post on the SharePoint 2013, Office Web Apps 2013 and Excel files with Data Connections post that I previously wrote. That post talked about how you needed to do, so called, WOPI Suppressions if you had Excel files with Data Connections and had those data connections configured to use the authenticated users account. The WOPI Suppression made sure that the rendering of the Excel book was done by Excel Services in SharePoint 2013 rather than with Office Web Apps 2013.
But if you have Excel documents with external data and do not rely on delegating the account (and don’t do the Negotiate, SPN and delegate dance), but instead like to store the credentials to the data in the connection string (not recommended) or like to take advantage of the Secure Store in SharePoint 2013 – then you actually have the option to not do any WOPI Suppressions. Let’s take a look on how you can get this to work: an Excel sheet with an external data connection using Secure Store to store credentials and then using Office Web Apps 2013 to refresh the data.
Configuring the Secure Store
First of all we need to have the Secure Store Service Application up and running in our SharePoint farm. Once that is done and you have generated the encryption key, we need to add a new Target Application. To create the Target Application use the New button in the Ribbon. This will take you to a wizard. First of all we need to give the Target Application an ID, this is what we later use to reference this application from Excel (and other sources). Also give it a descriptive name as well as a contact. Then we have to choose what type of Target Application Type to use. Use Individual or Group, where Group is preferred from a management perspective. If you choose Individual you have to set the credentials for each user individually and for Group you have one set of credentials per application.
On the next wizard page you set up the “fields” for the application. By default it assumes that it is Windows credentials that we would like to store, if that is the case you only need to click Next. Otherwise, if you’re using for instance SQL credentials, you have to set up two new fields using the User Name and Password type of fields. On the final page you give permissions to the Target Application itself and if it is a Group application then you also configure what users/groups that are mapped to the credentials.
When the application is configured we need to set the credentials for it. For a Group Application you use Central Administration or PowerShell to set the credentials to be used by the group of users. For Individual Applications you need to set the credentials for each and every user through Central Admin or create some custom Web Part or similar that the user can use to fill in it’s credentials. Fortunately most of the plumbing is already done for this. You can use the Layouts page called securestoresetcredentials.aspx to allow the user to set their credentials. This is how it is used:
You have to pass the TargetAppId as an argument and set the value to the Application ID of the application. Good to know here is that if you don’t use SSL/TLS (HTTPS) on you SharePoint sites you will get messages that will annoy your users, since this data will be sent in clear text. Just another reason to do HTTPS :-)
By now we should be all set to continue to the next step.
Create the Excel book with the Data Connection
Now it is time to create our Excel book. To do this we just add a data connection as normal but in the connection wizard we click on the Excel Services: Authentication button and then choose to use a stored account. In the stored account input box we have to enter the Secure Store Target Application ID, the one we created in the Secure Store Service Application above. Everything else is precisely as normal.
Now this workbook is ready to be uploaded to a document library in SharePoint. Good thing here is that now you don’t have to do anything more – no SPN’s, no nothing!
Refresh data using Office Web Apps 2013
So, let’s see if this works with Office Web Apps 2013! If you fiddled with the WOPI Suppressions as in my previous blog post, make sure to remove them so we have WAC rendering the Excel Sheet instead of Excel Services (this will work in Excel Services as well, but that is not the purpose of this post).
Click on the document so that it renders in the browser, make sure to update some data in the external data source so that you can see that the data is actually refreshed, then use Data > Reload All Data Connections to update the sheet. Everything should work fine here, your data should be refreshed.
So, there it is you can actually use Office Web Apps 2013 to render and refresh external data – only thing is that you can’t use any delegation features.
Didn’t it work? Of course things can go wrong. But a correctly configured environment should work immediately. Here are some of the common errors that you can get:
External Excel data connections disabled in Office Web Apps
Your admins (or you) might have turned of the Excel external data. You can check this by running the following command on a WAC machine:
If it returns false, then you have turned it off. By default when configuring a new farm it is set to true. If set to false and you want to use external data then use the following command:
Note that it can take a couple of minutes before changes like this actually is propagated in the WAC farm.
If this is your problem then you’re getting an error like this:
“The trusted location where the workbook is stored does not allow external data connections.”
You’re running SharePoint over HTTP!!!
The most common problem is that your SharePoint is still using HTTP and not HTTPS (when will you ever learn!). If that is the case you will get an error like follows:
“An error occurred while accessing application id XXX from Secure Store Service.”
This is perfectly normal and good! Since the SharePoint farm is accessible through HTTP this also means that Office Web Apps Server will try to retrieve the credentials over HTTP – in clear text, and you don’t want that.
But if you are running a development environment that uses HTTP it could be all right to work around this. Or you might be running IPSec (fat chance…) then it also ok to allow this. Otherwise I do recommend you to change your SharePoint content web application to use HTTPS or don’t just use the Secure Store and WAC.
Anyhow, this is how you configure WAC to allow retrieval of credentials over HTTP:
Once this command is executed, wait a minute, reload the workbook and you’re golden.
No credentials configured
Another common problem, common when using Individual Secure Store applications, is that the application does not have any credentials set. The error you will see then is the following:
“An error occurred during an attempt to establish a connection to the external data source.”
To fix this you have to set the Group credentials, if it is a Group application type, or make sure that all users set their individual credentials.
You have now seen that Office Web Apps 2013 can actually render external data, including refreshing it, using the SharePoint 2013 Secure Store service. Just be careful with the security issues I highlighted with SSL/TLS/HTTPS. All this will also work with plain ol’ Excel Services if you need to combine it with delegation.