I’m speaking at SharePoint Saturday in Charlotte, NC on August 10, 2019.  Below is an outline of things covered.

1. Envisioning
   1. Vision / Requirements
   2. Cleaning up
   3. Be Familiar with new SharePoint 2019 Server
2. Planning
   1. Migration or Upgrade?
   2. SharePoint / Project Server Architect
   3. Upgrade Path and Strategy
3. Building
   1. SharePoint Installation / Upgrade Scripts
   2. Upgrade Discovery and Issues
4. Stabilizing
   1. Finding and fixing SharePoint / Project Server Issues
5. Deploying
   1. The final upgrade

SharePoint Saturday Charlotte 2019

 

In this blog I ran across an interesting scenario that a customer requested.  The customer is running a three tier Project/SharePoint Server 2013 server farm on Windows 2008 R2 server.   The company required all servers to be on Windows Server 2012 R2 or higher and so the client wanted to migrate their Project/SharePoint 2013 farm to Window 2012 R2.  SQL server was not a concern, because it had already met the companies polices.

My first impression is why not migrate Project/SharePoint 2013 to either 2016 or 2019 and at the same time, install Project/SharePoint farm on Windows 2012 R2 servers.  Seems reasonable, however, the PMO (Project Management Office) didn’t want to migrate to newer version of project server, because of different SharePoint architecture, reports and customization.  This makes more sense to me now and so I came up with two possible scenarios to accomplish this with least impact.

• Install new SharePoint/Project server farm on new Windows 2012 R2 servers and then move databases and configure services on new environment.
• Swing new nodes in the existing farm by adding a new SharePoint front-end and app server on Windows Server 2012 R2 server. Configure app server to run same services as the 2008 R2 servers and then configure 2012 R2 front-end server

Three Stages of the SharePoint Swing

1) Original Farm on Windows Server 2008 R2 (above)

2) SharePoint Swing Farm on Server 2008 R2 and 2012 (above)

3) SharePoint Farm now running on 2012 (above)

It was decided to use the SharePoint Swing method.  The premise if fairly simple.  New windows 2012 R2 servers are created and SharePoint/Project Server is installed and configure.  The swing operation basically was the following

• Install two Windows Server 2012 R2 servers and install SharePoint 2013 on each node
• Join the new SharePoint servers to the SharePoint 2013 Farm. One as front-end tier and the other as app tier
• Using Central Admin add services to the new app and front-end SharePoint Servers
• Verify servers are working properly
• Shutdown old SharePoint front-end and app server. The SharePoint farm should continue to work without the redundant server.
• Optional after it is proven that the SharePoint has swung to the new SharePoint servers, the old servers can be remove and decommissioned.

Github provides PowerShell scripts to create a test environment in Azure using an IaaS architect.  https://github.com/MyProjectExpert/ProjectServer-Tools/tree/master/SharePoint2013Swing

Roadmaps have recently been release from Microsoft.  Roadmaps are a great way to summarize a PMO, Program, Project or anything that needs a summary.  When I first saw them, it seem like an easy thing to put together.  However, as I started to put together my Roadmap example, I released that its may be much harder than I thought.  After working thru a few examples, I discovered, that basically, it takes planning and a vision to make a Roadmap.  Duh!

Roadmaps can be used for many visions. One useful display of a Roadmap is to showing key milestones and dates in a program. My example is composed of several projects with dependencies between them. Visualizing key deliverable and milestones across a program can be best be done using a Roadmap.  When you think about it, there really isn’t any other tool within office to do this for user.  There hacks, web parts and web pages that a SharePoint admin could do, but not really one for typical users.  The following Roadmap consists of three projects, each with their own project manager and deliverable dependency between the projects.  Looking at my program Roadmap, I can easy determine the major deliverables and if it is on track on now.

As mention earlier, it takes planning and vision to build a Roadmap.  It may seem obvious now, but before building a program Roadmap in this blog, I had to go thru several iterations of a building my master project before I could get my Roadmap off the ground.  Once that was done, building my first Roadmap was simple.

 

Roadmap is like any other feature in Office 365; it must be turned on.  Brian Smith – MSFT provides the core steps with turning Roadmap on. https://blogs.msdn.microsoft.com/brismith/2018/12/07/project-online-getting-started-with-roadmap/

My blog provides the steps and along with screen shots of what you can expect to see.  Once “Roadmap” is turned on, the following option shows up when creating new projects or Roadmaps!

Default form for Project Online

Steps to enabled Project Roadmap:

• Office 365 Admin: Log into office 365 and click on “Admin” icon.  It may ask for your login credentials. https://www.office.com/?auth=2&home=1
• Settings and then “Services & addins https://admin.microsoft.com/AdminPortal/Home#/homepage
• Services & addins https://admin.microsoft.com/AdminPortal/Home#/Settings/ServicesAndAddIns
• Project Online and turn on “Roadmap” and click Save
• Make a note that “Project Online settings have been updated” and click Close
• If working properly it looks like top screen.

Office 365 Startup page

Office 365 Admin Center pager

Office 365 Admin with Service & addins listing services

Turn on Project Roadmap

Verify option enabled and click close.

When designing an Azure IaaS architect; should IaaS use a Windows Server AD VM or Azure ADDS for managing user and service accounts? The diagram below show two strategies.   The yellow arrow points to WCC2016AD, which is a windows 2016 server running AD. The red arrow points to Azure Active Directory. Each with their advantages and disadvantages.

Using Azure to setup IaaS environments for either TEST and QA is a great way to reduce costs. Typically for an on-premise solution, the organization’s support costs may double or triple for supporting a production application. TEST and QA environments are typically created for supporting application. This means additional hardware and software are added to the total cost for support. For a large IT shops this may not be a problem; however, for small and medium size, it can be a real burden.

Azure IaaS (Infrastructure as a Solution) can be a real cost saver if managed properly. The cost saving occurs when VM are turn off when not needed. When VMs are turned off, there is no billing for compute processing and disk storage is a relatively low billing item. In my small world, I can keep all my Azure costs below my MSDN subscription fees and thus not pay anything at end of month.

A typical IasS includes Front-End Server, Application Server, SQL Server, Windows 10 and Active Directory VM.  Typical for me, because I build and configure many different SharePoint environments and need a minimum of five server VMs. The Azure LAB environment provides a good enough environment to typical production environment. Over time, I have always wonder if it would be cheaper or better to use Azure ADDS or continue to use my Azure AD server VM.

The answer really depends on what you are doing and trying to accomplish. In my case, keeping costs down is important.   The ADDS cannot be disable. It can only be deleted and causes a lot of trouble when rebuilding. Because of this and many other factors, my preference is to continue to use the Azure Windows Server AD VM.   Spin it up when it is need and turn it off when done.

	Azure ADDS	Azure Windows AD VM
Cost	Minimum of $2 /day	Zero cost if VM is turned off
Managing Accounts	Useful (half dozen)	Useful (six)
Account creation	Must be done on Azure and synced	Not required using VM
Syncing User Profile	Required for testing AD Sync	Not needed unless testing

In summary, my preference is to use Azure Windows Server VM with Active Directory installed and configured to support my TEST and QA environment.

Microsoft announce Roadmaps during Ignite 2018.  To be perfectly honest, during the demo and afterwards, I didn’t find it very interesting.  It looked mostly like a One-Pager report that I had seen many years ago and Roadmaps implied that it was only for executives.  I attribute this view because One-Pager reports was developed for executive management that didn’t want to see many details.

Then it dawned on me that the Project Roadmaps was much more than what I originally thought and can be applied to many different visions.   The “Vision Roadmaps” can be used not only for executives, programs or projects but even small teams and personal goals.  Once I saw these capabilities, I was sold on it.

What are Project Roadmaps?

Basically, it’s a reporting dashboard that pulls project data from multiple sources, such as Microsoft Project, Teams and Visual Studio azure boards.  Then major deliverable are highlighted with different colored bars, milestones and dates making it easier to see the vision and how it’s going to be achieved.

Whats Next in Project Maps?

Microsoft Ignite announce it but it’s not out at the time of this writing (11/4/2018).   It’s pretty much ready for, however Microsoft will continue test, refine and enhance new feature until it met all of Microsoft requirements for integrating into the Microsoft’s Modern Solution; which means it runs as part of CDS (Common Data Service).  For example, Project Roadmaps is fully integrated into Flow and Power BI.