Last week, we hosted a webinar on Microsoft Lync, where my colleague Matt McGillen discussed how to integrate Lync with Cisco, or replace it.
During the session, Matt, Director of Infrastructure at Perficient, shared best practices and recommendations learned through his firsthand experience integrating with Microsoft UC and Cisco. With many organizations struggling to figure out how to make Lync work with their existing investments in legacy Cisco IP telephony, he took a deep look at the best ways to leverage Lync in addition to an existing Cisco infrastructure.
First, Matt talked through the decision of how to integrate – starting by defining your requirements, using the best tool for the job, and next segmenting user populations. Then, he went on to review three ways to integrate:
He explained what each option entailed, giving both the advantages and disadvantages while providing attendees with special considerations to take into account.
If you missed the webinar, you can listen to the presentation in its entirety, along with the Q&A portion, here:
You can also review the webinar slides, along with the poll results:
With Forefront TMG discontinued and Forefront UAG not supported for all Lync scenarios (hint, hint: mobility), customers will be increasingly looking at deploying ARR to serve as their reverse proxy solution for Lync. The good news is that ARR is fully capable and supported for the reverse proxy role; the bad news is that ARR is still relatively new for this scenario and not all issues are well known or easy to uncover. While working on a Lync 2013 deployment with a customer I ran into an interesting ARR issue specific to mobility clients. All other mobile clients worked but when iOS users attempted to sign-in via their Lync 2013 mobile client they received a “We can’t connect to the server…” error and were unable to successfully sign-in.
To verify I didn’t have a mobility misconfiguration in the environment I used the Lync Connectivity Analyzer to test things out. The results from LCA showed that the minimum requirements passed, which should indicate the ability to utilize mobile devices:
Completed tests for the Mobility (MCX) service.
Your deployment meets the minimum requirements for Lync mobile apps.
Additionally, I was able to successfully browse to all the required external Lync URLs via Internet Explorer using an external PC so I knew that the ARR URL rewrite rules were successfully configured. Despite everything passing and appearing to be externally available, iOS users continued to be unable to sign-in via the Lync 2013 mobile client, so I had to dig a bit deeper.
My first additional examination was to look at the IIS logs on the ARR server to verify there were no unusual HTTP responses or errors during the client login sequence. When looking at the IIS logs I could see that requests were sometimes receiving an HTTP 502 response (Bad Gateway). Based on the user agent header in the ARR logs those 502 requests seemed to correspond with the iOS Lync 2013 client, so I went sleuthing on the Internet for some assistance. My Bing-Fu must have been strong that day because in my searching I was able to come across a TechNet post that closely matched the issue I was seeing. Even more helpful was that the post contained information for a hotfix for Server 2012 ARR – KB2732764:
Hotfix for Microsoft Application Request Routing Version 2.5 for IIS7 (KB2732764) (X64)
This hotfix addresses a problem in Application Request Routing Version 2.5. When ARR is installed on Windows Server 2012 it fails to proxy Windows authentication.
After downloading the hotfix and installing it on the Windows Server 2012 ARR server, iOS clients were able to connect successfully! Eventually this hotfix might be automatically downloaded and installed when you run through the ARR installer (via the IIS Web Platform installer), but for now make sure you include this particular hotfix in your ARR builds to avoid any issues with Lync 2013 mobility clients when using ARR for your reverse proxy.
Yesterday, CMSWire.com published an article written by my colleague, Rich Wood. In the essay, (R)Evolution: The Past, Present and Future of the Social Enterprise, Rich discusses how social collaboration tools represent not a revolution (yet), but an evolution of organizational communication.
Rich begins by explaining:
It’s been too easy to claim that introducing newsfeeds, microblogging, @targets and #tags to the enterprise represents some sort of revolution in the way organizations communicate. It doesn’t. If anything, it’s an evolution, not a revolution — but the pieces are in place to get there in the near future.
He justifies this quite simply, stating that in many ways, enterprise social networks are just a new channel allowing people to do something they’ve done since the beginning of time – talking to each other. Over time, technological advancements have been made, but the use case has always remained the same. But, the promise of enterprise social networks is that they leverage the power of the network to engage others in that dialogue. This knowledge sharing adds value – when it works.
Here’s a valid point:
But it doesn’t always work, and it certainly doesn’t always work naturally. As much as some in the industry want us to believe that social adoption is “viral”, it’s rarely that easy and besides, “viral” rarely sounds like a good thing to people outside of marketing. It doesn’t matter how groundbreaking your technology is if you don’t have people on the network buying in, checking the newsfeed (or their alerts from the newsfeed) and participating because they inherently want to. Getting enterprise social networks to work means creating that “want-to.”
What does that mean? It means that people engage on social networks because it is something that intrinsically matters to them. It’s about people and issues close to home, matters that they can engage with. This isn’t something that can be created – more so, it is something you have to tap into.
Even when there’s a common platform — which makes the most strategic sense — getting an enterprise to adopt that platform across the board is hard. You need to have people who interact locally before they can add value by interacting globally.
Then you can start talking about truly enterprise social. And only when you’ve achieved a truly social enterprise can you start talking about revolutionary new applications of this technology, because a revolution is about doing something entirely new, not finding a new way to do something old. Read the rest of this post »
It’s been a big month around here in a lot of ways. Most importantly, our team was recognized as Microsoft’s 2013 US Partner of the Year. From a personal perspective, I’m really thrilled to be able to tell you that I’ve just had an essay published over at CMSWire.
The topic is something that will be familiar to regular readers here, or clients and audiences I’ve presented to in the last six months– the way social collaboration tools represent not a revolution, but an evolution of organizational communication.
I’ve never been a fan of hype, and social business has definitely known its fair share. I’ve tried to take a more measured approach, studying the tools in context of what’s come before– and I even lay out where I think these tools need to go if they’re ever to truly become revolutionary.
Check it out if you’ve got a few minutes. I hope you find it thought-provoking.
Microsoft came out with Windows Intune Wave D not to long ago, and now are alreay touting a new version, I am assuming it will be E or Version 5.
From what I have been seeing, this iteration is part of a larger set of product updates that are coming through the end of the year. System Center R2, Server 2012 R2, Windows 8.1 (Blue).
Microsoft is doing some really great things with these upcoming releases, and when you combine them all it seems to be quite powerfull, from the sneak peaks I have seen released at TechED 2013.
The one thing I am hearing, is the new Version of Windows Intune will be more tightly intergrated into Configuration Manager 2012 R2, This will make more a singel pane of glass feel.
From what I understand here is a high level list of new features that will be coming to Windows Intune E.
I think over these next few months, it will be interesting to see if these features or anything else will be added to Windows Intune. Also to see how integrated Windows Intune will be with the new releases.
Organizations choose SharePoint as an enterprise collaboration, productivity, insight and analysis platform in order to drive business value. If SharePoint is a lever, then governance directs the force placed on that lever to achieve maximum leverage. In this white paper, “The SharePoint Site Governance Lifecycle Model,” Perficient introduces the five stages of its SharePoint Governance Lifecycle model.
The white paper describes a simple process model for how we approach a certain topic in the SharePoint world: site governance. “Site” refers to one of the central organizing elements of the SharePoint platform: the site. “Governance” refers to a set of policies, principles, processes, and tools for managing various aspects of a SharePoint installation. The amount of governance an organization should generally be proportional to the degree to which you are leveraging SharePoint— that is, how many sites you have, and how many different types of people are using them.
This paper explains how to drive value and manage change – but what does that mean, exactly? Even though “managing change” is one of the most commonly emphasized aspects of SharePoint governance; it is not the only aspect. The other aspect of SharePoint governance we like to emphasize here at Perficient is “driving value.” Why? Because you’ve likely adopted SharePoint for reasons that have to do with creating value within your organization.
Download the white paper to learn more about this topic.
Just two short weeks ago, Perficient was named Microsoft’s 2013 U.S. Partner of the Year! This is an amazing honor; it’s probably the single biggest achievement a partner consultancy can realize, and I’m fortunate enough to be part of the team that earned it. It doesn’t happen every day, nor every year, and certainly not to every SharePoint partner—so I wanted to take some time and reflect on exactly what it means to me, personally, as a part of our SharePoint team.
Special Award = Special Team = Special People
This is truly a rare and prestigious award—and they gave it to a rare and special bunch of people. I’ve been working with SharePoint for almost ten years now, but never around talent like this. I started as an IT architect with an enterprise customer, then moved to a local boutique systems integrator where I started a content and collaboration practice that grew like crazy once I got them into some enterprise accounts. I moved to Microsoft, where I was a SharePoint specialist in the field (and nearly a technical product manager on the SharePoint team). But nothing I’d ever done had prepared me for working with the incredibly talented teammates I’ve had over the last eighteen months at Perficient.
It’s an amazing feeling to wake up and go to work with experts every day, and respect every last one of them. And these aren’t just people you respect because they’re smart, but people you respect because they’re thoughtful and funny and clever and kind, brilliantly strategic and sharply tactical, great at what they do and always happy to lend a helping hand. From a people perspective, it’s no surprise to me that we’ve won. If you want to recognize a great partner, then you’re probably going to recognize one with great people.
We Earned This In Every Way Possible
You don’t get recognized for excellence on a nationwide stage because you’re great at one thing. You get recognized because you do a lot of things, and you do them well. Our delivery teams do SharePoint, sure, but also Lync, Exchange, Office 365, custom development (on premise and Azure), CRM, Systems Center, even Sitecore. Think about this:
And those are just the ones that spring quickly to mind. I didn’t even go into Business Intelligence, CRM, Windows InTune or other cool things we do. In short, you have to be a pretty busy Systems Integrator to beat out all the software vendors and device manufacturers Microsoft partners with, never mind the vast network of other SI partners (thousands and thousands, mind, all told). We are definitely that.
It’s More Than Technical Brilliance (Although That Helps)
We have a core set of values here at Perficient that pervades every level of our organization, and I can clearly see how each function here directly contributed to this honor. How our Sales, Marketing, Alliances, Operations and management teams played a part in this thing through their own passion, execution, and dedication is something I can’t undersell—any more than I can enthuse about the fun of working with an expert technical staff. This truly is a great team and I’m honored to have been a part of it for the last year and more. I’m looking forward to doing ever more incredible things together. Ping me on LinkedIn if you’d like to come along for the ride.
Thanks for reading!
–Rich
I recently got to see the first Responsive Designed-Sitecore powered site I have ever worked on go live. If you’re not familiar with Responsive Design…well, where have you been? Seriously though, Responsive Design is a pretty big buzzword in not just the tech industry but in any business that wants to be relevant in today’s ever changing world. I’m certainly no designer, but I think I can boil the concept down to its basic pretty well if you’re still not sure what I’m talking about. Responsive Design is the concept of using one set of HTML / CSS markup that looks optimal for any screen size. It’s a big deal because the mobile and tablet computing markets are exploding and surpassing traditional PC’s and laptops for usage right now. If your website is not utilizing Responsive Design, it probably means you need completely separate sets of code to ensure your visitors are seeing optimal content regardless of their device.
At this point, you may be asking “Jamie, if this is such a hot topic, how come you’re first site using it just launched now?” That’s certainly a fair question, and I hope I have a fair answer. The first and foremost answer is that Sitecore comes with a concept of devices out of the box. These devices make developing your presentation on different devices really easy, which means that it’s completely possible to have optimal experiences on all devices without a lot of hassle when a site is built on Sitecore. The second reason is that like most things in life, Responsive Design is a choice, and with that choice is an opportunity cost. I’ll spend the rest of this post covering what I see as the pros of choosing to use Responsive Design as well as the opportunity costs of choosing to implement a Sitecore powered site using Responsive Design.
Let’s start with the pros as I see them. First, Responsive Design is a current buzzword, and implementing a site on top of it can give you some bragging rights. We all know bragging rights don’t equate to dollars in business, however bragging rights communicated properly can equate to increased web traffic – which can in turn equate to dollars. Responsive Design can be pretty cool looking too – if you’re on a full-size browser, navigate to a Responsive Design site and start playing with the width of your browser screen. It’s certainly cool to watch the screen rearrange itself to remain optimized. As fun as that is initially though, I don’t know of any real life visitors who go through the web constantly changing their browser size, so there’s really no benefit to the “coolness” factor of Responsive.
When talking about Sitecore implementations, another pro regarding Responsive Design is that the back end code can arguably be made with less effort. The reason is that with Responsive Design, I’ll only have one set of markup, and I can code my back end functionality directly into the code behind of that markup. If I’m going to use the Sitecore device concept, then I’m better suited taking that back end code and putting it in common classes that are called from the code behinds of my full size markup and my tablet markup and my mobile markup, etc. The amount of code varies little, but the complexity may be increased using the device concept. The fact that responsive only requires 1 set of markup reduces the amount of sublayouts I need to create in Sitecore, which can reduce development time and maintenance. It can also help with technical understandability and the ability to transfer site ownership to new developers.
Another thing about Responsive Design is that it takes a pretty experienced designer to do it well. That means that you’re probably going to completely separate the responsibilities of design from your back end developers. Depending on the environment, this may be a pro, or it may be a negative. If you already have a solid design team and a solid development team who work great together, separating their responsibilities can mean better throughput for both.
Now that we’ve covered the benefits of developing your Sitecore site with Responsive Design, what are those opportunity costs? The first is that typically, designing the site using Responsive is going to elongate the design period. This elongated design period can put the rest of your projects timeline in jeopardy, and maybe even cause you to try to do some tasks, like Information Architecture in parallel to design. Parallel IA can be done with design, though it certainly poses a risk that the outcomes of each activity don’t match each other and you’ll need a period to revise one or the other (or both) so that they can match. Speaking of elongated times, in my experience, you should expect to see a lengthened period of time for your sites QA stage. This is because a change to one device’s markup is tied to all the other devices. For example, if you want to adjust something on your desktop view to be centered, that change could inadvertently break your table and / or mobile device views. To combat this, any change made automatically has to be tested on every device size – and if a problem was introduced in the fix for your desktop, then you need an alternative fix that will not present as an issue on other devices. (Trust me, there’s nothing worse than introducing a fix for one view only to find out you forgot to test another view and then being told that view is broken!) In contrast, when developing using Sitecore devices, a change to the presentation of the desktop layout is completely insulated from the mobile view, so you don’t have to worry about inadvertently affecting a separate device.
Going back to the last pro of Responsive – if you don’t already have that solid design team and development team, now you’re looking for one or both – which means higher cost up front. Even if you have both already, if they don’t play well together, that can lead to issues. Luckily on my implementation, we worked very well with the design team, and had a very competent design team to work with, so we didn’t encounter this issue. I could easily see a lot of issues arising if there’s not a very high level of communication and trust established from day one between these teams though. If the developers have enough HTML / CSS knowledge to be dangerous, they can start changing presentation on their own – and not even maliciously. We’ve all heard the “if you want something done right…” saying before, but as a developer it’s easy to not only think that way but to also think “if I make this change myself, I can do it in 5 minutes and not have to involve anyone else – yay for higher production!”. If you’re using Responsive, that’s a very dangerous thought – you’re running the risk of breaking something you don’t even know you’re breaking. This type of thing can set the project schedule back very quickly and easily. Because of this, I think it’s safe to say that a negative of implementing Responsive Design is that all changes need to be exposed through your design team to confirm that they won’t break anything in the Responsive set.
Another cost of Responsive Design is the amount of client side code that is required to make it work. That means you’re throwing a lot over the bandwidth of the network in order to make sure that the site renders on all sized devices. As I’ve already mentioned though, outside of the fringe case of the person who just thinks it’s cool that your site changes when they resize their browser, why would you need the site to work for all browsers at once? It’s much more efficient, thus faster to only send the design that is necessary for the particular device that is currently being used rather than to have to account for all them. After all, a mobile device user can never change their browser to be larger than the size of their phone screen, so why send the user data that handles that case? Conversely, with the Sitecore Device separation of presentation, you are only sending them what they need to see your site optimized on their device. That will result in better performance for the visitor. Personally, I think this outweighs the “coolness” factor of Responsive.
A final cost is the considerations of any non-Sitecore technologies you’re integrating with. Sitecore has plenty of technology partners, and a lot of Sitecore sites integrate into custom-built Services and sites as well. If those technologies aren’t ready or built for Responsive Design themselves, you may find that you’re now implementing a hybrid “some Responsive / some not” site. This adds to the complexity of developing, maintaining and training on your site because now there’s some code that’s Responsive and some not and your technical team has to keep track of what is what.
From the list above, I hope it’s clear that there are certainly both strengths and weaknesses to utilizing Responsive Design for a Sitecore powered site. Because of this, I don’t think there’s a clear cut recommendation of “Always use Responsive with Sitecore” or “Never use Responsive with Sitecore”. Instead, clients must weigh the above pros and cons and decide the proper path for their website(s). Shameless plug time – Perficient’s Sitecore Practice and XD teams would love to help anyone out with that decision so that the best outcome is achieved. Finally, I would love to hear from any implementers or clients who’ve used Responsive Design for a Sitecore site. What were your thoughts on it, and would you recommend it or against it?
It is clear by now that SharePoint 2013 offers up some big changes, particularly around search and social functionality. For starters, Fast Search is now part of SharePoint in the new release. This means that SharePoint 2013 can easily index content from a wide variety of different sources. By taking the Fast solution and combining it with SharePoint’s native search capabilities, SharePoint 2013 delivers a much more dynamic interface with an improved, engaging social user interface.
There is no doubt – by putting internet-class search power in the hands of business users, SharePoint 2013′s new search features stand ready to power the next generation of internet and intranet search solutions.
To learn more about these new features, join us for a Perficient webinar on Thursday, June 27 at 1 PM CT. During SharePoint 2013 Search & Social – What You Need to Know!, Senior Technical Consultant Will Tseng and SharePoint Practice Director Rich Wood will cover key components of designing and delivering optimal search experiences, while also discussing the platform’s extensive social collaboration capabilities.
To register for the webinar, click here.
SharePoint 2013 Search & Social – What You Need to Know!
June 27, 2013
1:00 p.m. CT
One of the keys to Microsoft’s strategy to make Azure a clear choice for customers of every size is the idea that you get massive scalability to meet demands, but only have to pay for capacity that you’re actually using at any given point in time. Until today, that statement has always come with its own asterisk because the reality was that you only pay for the capacity of which you use any portion of an hour. That might seem insignificant, but for a customer running thousands of VMs, the difference value received by 61 minutes of runtime and 120 minutes of runtime can be huge and the cost has been the same. Microsoft announced today in this blog post and through several newsletter channels that effective today Azure will be billed by the minute – effectively making 61 minutes of runtime cost far less than the same time on competitors’ products. These changes along with Microsoft’s commitment to maintaining competitive pricing make implementing solutions on Azure as attractive to the CFO as it is to the CIO.
RSS Feed
-bpfull.jpg&w=24&id=118&random=1350014505 "Joe Crabtree"){kind=avatar}
