Wednesday, July 26, 2017

Holiday

This blog will be silent for the next few weeks because I am going on holiday, enjoying my family to the fullest.
Image result for national lampoon's european vacation
(Picture from the movie ‘National Lampoon's European Vacation’)

After the holiday ‘I’ll be back’ with quite a few postings, like (but not limited to):

  • The 2 last postings for the series about the future of the System Center stack related to Microsoft’s  ‘Cloud & Mobile First’ strategy;
  • Quite a few postings about Azure (IaaS & management);
  • SCOM updates and the lot.

I wish everybody a nice holiday (if not already enjoying it) and see you all later.

Bye!

Thursday, July 20, 2017

‘Mobile First–Cloud First’ Strategy – How About System Center – 05 – SCSM


Advice to the reader
This posting is part of a series of articles. In order to get a full grasp of it, I strongly advise you to start at the beginning of it.

Other postings in the same series:
01 – Kickoff
02 – SCCM
03 – SCOrch
04 – SCDPM
06 – SCVMM
07 – SCOM


In the fifth posting of this series I’ll write about how System Center Service Manager (SCSM) relates to Microsoft’s Mobile First – Cloud First strategy. Like SCOrch I think that SCSM isn’t going to make it to the cloud…

Ever heard of Service Desk?
The very start of SCSM was a bumpy ride. Originally it was code-named Service Desk and was tested back in 2006, with the release scheduled somewhere in 2008. The beta release ran on 32-bits(!) version of Windows Server 2003, with IIS 6.0, some .NET Frame work versions (of course), SQL Server 2005 and SharePoint Server 2007 Enterprise.

Service Desk was really a beast. Terrible to install, a disaster to ‘run’ (it was slooooooooooooooow) and filled to the brim with bugs. Totally unworkable. Back then I was part of a test team which put the ‘latest & greatest’ of Microsoft’s products through its paces. The whole team was amazed about the pre-beta level of it. Never ever before we bumped into such crappy software. We even wondered whether we had received the proper beta bits…

So none of us was surprised when Microsoft pulled the plug on it and sent the developers back to their drawing boards. In the beginning of 2008 Microsoft officially announced it was delaying the release until 2010, because the beta release had performance and scalability issues. Duh!

Meanwhile a new name was agreed upon: Service Manager.

2010: Say hello to SCSM 2010
In 2010 the totally rewritten SCSM 2010 was publicly released at MMS, Las Vegas. For sure, the code base for SCSM 2010 was totally new, but somehow the developers had succeeded in bringing back some of the issues which plagued Service Desk: performance and scalability issues… Ouch!

Because SCSM 2010 was really the first version (totally rewritten code remember?) it missed out on a lot of functionality. As a result Microsoft quickly brought out Service Pack 1 for it, somewhere in the end of 2010. For SCSM 2010 SP1 in total 4 cumulative updates were published, alongside a few hotfixes.

From 2012x to 2016 in a nutshell
Sure with every new version (2012, 2012 SP1, 2012 R2 and 2016) the performance and scalability issues were partially addressed, but never they really disappeared. As a result SCSM has a track record for being slow and resource hungry. For SCSM 2016 Microsoft claims that data processing throughout has been increased by 4 times.

None the less, the requirements for SCSM 2016 are still something to be taken seriously. For instance, Microsoft recommends physical hosts, 8-core CPU’s and so on. The number of required systems can run over 10+(!), especially when you want to use Data Warehouse cubes and the lot. Even for enterprises this is quite an investment for just ONE tool.

Also with every new version, additional functionality was added. For instance, SCSM 2016 introduced a HTML based Self Service Portal. Unfortunately, the first version of that portal had some serious issues, most of them addressed in Update Rollup #2.

All in all, the evolution from SCSM 2010 up to SCSM 2016 UR#2 has been quite a bumpy ride with many challenges and issues.

Deep integration
Of course, SCSM offers a lot of good stuff as well. It’s just that SCSM is – IMHO – the component of the SC stack with the most challenges. One of the things I like about SCSM is the out-of-the-box integration with other tools and environments.

SCSM can integrate with AD, other System Center stack components (SCOM, SCCM, SCVMM and SCOrch). And – still in preview – you can use the IT Service Management Connector (ITSMC) in OMS Log Analytics to centrally monitor and manage work items in SCSM. As a result, the underlying CMDB is enriched with tons of additional information for the contained CI’s.

SCSM & Azure
At this moment – besides the earlier mentioned ITSMC in OMS – there are no other Azure Connectors available, made by Microsoft that is. There are some open source efforts, like the Azure Automation SCSM Connector on GitHub. But as far as I know, it isn’t fully functional.

Other companies like Gridpro and Cireson, are offering their solutions. But since these companies do have to earn a living as well, their solutions don’t come for free, adding additional costs to your SCSM investment. Still, some of their solutions resolve SCSM pain points for once and for all. So in many cases these products deserve at least a POC.

But still the Azure integration is limited. On top of it all, Microsoft itself doesn’t offer any Azure based SCSM alternatives. Azure Marketplace offers a few third party Service Management solutions (like Avensoft nService for instance) but none of them Microsoft based.

Of course, you could  install SCSM on Azure VMs, but shouldn’t since it’s a resource savvy product, which would bump up Azure consumption (and thus the monthly bill) BIG time.

No Roadmap?!
Until now Microsoft is pretty unclear about their future investments in SCSM. There is nowhere a roadmap to be found. So no one knows – outside Microsoft that is – what will happen with SCSM in the near future. Will there ever be a new version after SCSM 2016? I don’t know for sure. But the signs are the tell tale sign their won’t be…

ServiceNow
In the last years the online service management solution ServiceNow has seen an enormous push and growth. Not just in numbers but also in products and services.

Basically ServiceNow delivers – among tons of other things – SCSM functionality in the cloud. Fast, and reliable. It just works. Also it integrates with many environments, tools and the lot.

Verdict
SCSM has a troublesome codebase which isn’t easily converted to Azure without (again Smile) a required rewrite. When looking at where SCSM stands today, the reputation it has, I dare to say it’s end of the line for SCSM. No follow up in the cloud, nor a phased migration (like SCDPM or SCCM) to it.

Instead Microsoft is silent about the future of SCSM which on itself says a lot. One doesn’t need to speak in order to get the message across.

Combined with the power of ServiceNow, fully cloud based, it’s time to move on. When you don’t run SCSM now, stay away from it. Because anything you put into that CMDB must be migrated to another Service Management solution sooner or later. Instead it’s better to look for alternatives, using todays technologies to the fullest, like ServiceNow or Avensoft nService. For sure, there are other offerings as well. POC them and when they adhere to your company’s standards, use them.

When already running SCSM, upgrade it to the 2016 version. It has Mainstream Support till 11th of January 2022. Time enough to look out for alternatives, whether on-premise or in the cloud. Because SCSM won’t move to the cloud nor will Microsoft invest heavily in it like it did before it adopted their Mobile First – Cloud First strategy.

So don’t wait until it’s 2022, but move away from SCSM before that year, so you can do things on your own terms and speed, not dictated by an end-of-life date set for an already diminishing System Center stack component.

Coming up next
In the sixth posting of this series I’ll write about SCVMM (System Center Virtual Machine Manager). See you all next time.

Monday, July 17, 2017

Azure Stack and Azure Stack Development Kit Q&A

Since Azure Stack is GA, many questions have come forward. Not only about Azure Stack but also about Azure Stack Development Kit. I’ll do my best to answer most questions and refer to the online resources as well.

01: What’s Azure Stack?
As Microsoft states: ‘Microsoft Azure Stack is a hybrid cloud platform that lets you deliver Azure services from your organization’s datacenter…’. Still it sounds like marketing mumbo jumbo.

Basically it means that with Azure Stack your organization has the same Azure technology on-premise available, deeply integrated with the public Azure. Of course, Azure Stack doesn’t offer the same breadth and depth of services as the public Azure, but still it packs awesome cloud power. It’s to be expected that with future updates Azure Stack will offer more and more public Azure based services and technologies, based on the use cases and demands of existing Azure Stack customers.

And because Azure Stack and the public Azure use the same technologies, the end user experience is fully transparent. The same goes for the administration experience. So basically Azure Stack can be looked upon as an extension of Azure.

So yes, one could look at Azure Stack as a kind of private cloud which can be heavily tied into the public Azure, thus creating a super powered hybrid cloud. But there is more.

02: Does Azure Stack require a permanent connection with public Azure?
No, it doesn’t. You can run Azure Stack either in a Connected scenario or Disconnected scenario. In a Connected scenario Azure Stack has a permanent connection with the public Azure. In a Disconnected scenario, Azure Stack doesn’t have a permanent connection.

Even though the first scenario – Connected – makes the most sense, there are enough valid use cases for the Disconnected scenario as well. Think about area’s with a low internet connection density combined with a far away public Azure region. Or how about hospitals, embassies, military installations and bases? The kind of information kept and processed in places like those are valid use cases for the Disconnected scenario.

03: Why should companies use Azure Stack while public Azure offers more services and is more powerful?
Good question! Suppose you’ve got a production facility which generates HUGE amount of data. That data is processed, and the result sets are used further down the production line. In a public Azure setup it would require an enormous data pipeline to Azure in order to get that data across. And when processed, the result sets have to send back as well. Which is egress traffic = money. On top of it all there is latency since the data travels between the factories and Azure.

With Azure Stack, that data is processed locally (no data traffic costs since it’s local LAN, no WAN) and there is no to very small latency.

Another valid use case is app development. Here public Azure is used for development and Azure Stack is used for production, or vice versa.

Or how about sensitive data which – based on regulations and law – isn’t allowed to live in the public cloud? Now you can keep the data onsite (Azure Stack) and use apps living in the public Azure.

And these are just some of the valid use cases for Azure Stack. There are many more, believe me.

04: Does Azure Stack offer the same services as the public Azure?
No, it doesn’t. Which makes sense when you compare the size of an average Azure region compared to an Azure Stack Smile. However, as stated before, the amount of services offered by Azure Stack will grow in the future, based on customer demand and use-/business cases for Azure Stack.

For now(*) Azure Stack offers these foundational services:

  • Compute;
  • Storage;
  • Networking;
  • Key Vault.

On top of it, Azure Stack offers these PaaS services(*):

  • App Service
  • Azure Functions
  • SQL and MySQL databases

(*: This is per 10th of July 2017. Since Azure Stack is in constant development, changes are that the amount of services offered by Azure Stack will have changed over time. Please check Microsoft for the most recent updates and overview of services offered by Azure Stack.)

05: Can I download Azure Stack and install it on spare hardware I’ve got?
No, you can’t. Because Microsoft invests hard to offer you the same Azure experience (pay as you go, consume with no worries about the hardware and so on) with Azure Stack, they had to lock down the hardware on which Azure Stack runs.

Therefore Azure Stack is delivered as a whole package, hardware and software integrated into one. For now HPE, Dell EMC and Lenovo deliver Azure Stack with their own hardware. Soon other hardware vendors will follow suit.

06: So I can’t test drive it? How do I know whether Azure Stack works for me?
Sure you can test drive Azure Stack, POC it or use it as a developer environment. For this Microsoft has specifically developed Azure Stack Development Kit.

You can download it for free and install it on hardware of your choice. Of course there are some requirements to be met for this hardware, but still it’s up to you what vendor to use.

07: What’s Azure Stack Development Kit? Can I use it for production?
As Microsoft states: ‘…It’s a single-node version of Azure Stack, which you can use to evaluate and learn about Azure Stack. You can also use Azure Stack Development Kit as a developer environment, where you can develop using consistent APIs and tooling…’

As such Azure Stack Development Kit isn’t meant for production. It’s meant for POCs and stuff like that. Go here to learn more about it.

08: Do I need to pay for Azure Stack?
Sure you do. But the prices are lower compared to using the public Azure. Which makes sense because your company pays the hardware and operating costs. Check out this Microsoft Azure Packaging & Pricing Sheet (*) for more information.

(*: Please know this sheet will be updated in the future. As such, just Google for Microsoft Azure Packaging and Pricing Sheet and you’ll find the latest version of it.)

09: Is Azure Stack Development Kit free?
Yes, Azure Stack Development Kit itself is free. However, the moment you connect it to (one of) your Azure subscriptions and start moving on-premise workloads to the public Azure, you will be charged for it.

10: Do have some useful links for me?
Sure, hang on. Here are some useful links, all about Azure Stack and/or Azure Stack Development Kit:

Thursday, July 13, 2017

‘Mobile First–Cloud First’ Strategy – How About System Center – 04 – SCDPM


Advice to the reader
This posting is part of a series of articles. In order to get a full grasp of it, I strongly advise you to start at the beginning of it.

Other postings in the same series:
01 – Kickoff
02 – SCCM
03 – SCOrch
05 – SCSM
06 – SCVMM
07 – SCOM


In the fourth posting of this series I’ll write about how System Center Data Protection Manager (SCDPM) relates to Microsoft’s Mobile First – Cloud First strategy. Even though it’s a bit ‘clouded’ it’s pretty sure SCDPM will move to the cloud, one way or the other. But before I go there, let’s take a few steps back and take a look at SCDPM itself.

SCDPM
From the very first day it saw the light SCDPM was different compared to other backup products. For instance, Microsoft positioned it as a RESTORE product, not a backup product. By this Microsoft meant to say that as a SCDPM admin you could easily restore any Microsoft based workload, like SQL, Exchange, SharePoint and so on, WITHOUT having any (deep) understanding of the products involved.

Even though SCDPM’s usability was limited to Microsoft workloads, it offered a solution to the ever growing amount of data to be backed up with a never growing backup window: continuous backup!

Therefore SCDPM offered something new, if only a refreshed approach to the backup challenges faced by many companies back then.

Unfortunately Microsoft dropped the ball on SCDPM some years later on, because further development of new functionalities and capabilities was stopped.  As such it was overtaken by many other backup vendors, delivering improved implementations of continuous backup and easiness of restore jobs.

On top of it all, SCDPM kept it’s focus on Microsoft based workloads. Only for a short period SCDPM was capable of backing up VMware based VMs (SCDPM 2012 R2 UR#11), to be abandoned when SCDPM 2016 went RTM. Sure, one of the reasons being that the VMware components required to be installed on the SCDPM server to support VMware backup isn’t yet supported on Windows server 2016. None the less, the result is the same: SCDPM covers Microsoft based workloads only.

Combined it has led to an ever shrinking market for SCDPM. With Microsoft’s strong focus on Azure it looks like SCDPM is going to the cloud, one way or the other.

SCDPM & Azure
Valid backup strategies are vital for any company, whether working on-premise, in the cloud or hybrid. Therefore Azure offers different backup services, which are potentially confusing. Even more confusing because the starting point for consuming Azure backup services is the same.

It all starts with creating a Recovery Services Vault which is an online storage entity in Azure used to hold data such as backup copies, recovery points and backup policies. From there one can configure the backup of Azure or on-premise based workloads.

When choosing to backup on-premise based workloads there are three options to choose from:

  1. When you’re already using SCDPM, you have to download and install the Microsoft Azure Recovery Services (MARS) Agent:
    image
    The MARS Agent is installed on the SCDPM server. Now SCDPM will be extended from disk-2-disk backup to disk-2-disk-2-cloud backup. The on-premise backup will be used for short-term retention and Azure will be used for long-term retention.


  2. Of course, the MARS Agent can be used outside SCDPM as well, in which case you have to install and configure it separately on every server/workstation you want to protect. In bigger environments this creates enormous overhead.

    As such this approach should be avoided and is only viable in smaller environments where you have just a few on-premise laptops/workstations to protect and run everything else in the cloud (Azure/AWS).


  3. When you don’t use SCDPM, you have to download and install Microsoft Azure Backup Server (MABS) v2:
    image

    MABS is actually a FREE and customized version of SCDPM with support for both disk-2-disk backup for local copies and disk-2-disk-2-cloud backup for long term retention. And contrary to SCDPM, MABS supports the backup of VMware based VMs!

    Of course, the moment you start using Azure for long term retention, you’ve to pay for the storage used by your backups. And the moment you restore from Azure to on-premise or to Azure in another region, you have to pay for the egress traffic.

    On top of it, MABS requires a live Azure subscription. The moment the subscription is deactivated, MABS will stop functioning.


When using a Recovery Services Vault to backup Azure based workloads you can only backup Azure VMs, which is an extension to an Azure VM. This will cover the whole VM and all related disks to that VM. The backup will run only once a day and a restore can only be done at disk level.

Azure Site Recovery
And no, this isn’t everything there is. Another option is Azure Site Recovery.

As Microsoft states: ‘… (it) ensures business continuity by keeping your apps running on VMs and physical servers available if a site goes down. Site Recovery replicates workloads running on VMs and physical servers so that they remain available in a secondary location if the primary site isn't available. It recovers workloads to the primary site when it's up and running again…’

Too many choices to choose from?
As you can see, Azure offers different backup services, aimed at different scenario’s. Also SCDPM can be used together with Azure backup, turning SCDPM into a hybrid solution.

And SCDPM can be installed on an Azure VM and the same goes for MABS, enabling you backup cloud based workloads running on Azure based VMs.

Even more options to choose from! To make it even more confusing, Azure is in an ever state of (r)evolution. What’s lacking today, is in preview tomorrow and next week in production. The same goes for Azure backup services and Site Recovery.

Verdict
SCDPM is moving to the cloud. Or better, it has already arrived there. One way is using SCDPM in conjunction with the MARS Agent, another way is installing SCDPM on Azure based VMs. Or instead, using the revamped and customized free version of SCDPM, branded MABS. Which can be installed on-premise or on Azure based VMs.

So there are choices to be made. The right choice depends much on the type of workloads your company is running, combined with the location (on-premise, cloud or hybrid) and the Business Continuity and Disaster Recovery (BCDR) strategy in place.

On top of it, the moment of your decision is also important. Simply because Azure backup services are just like Azure itself, changing and growing by the month. This Microsoft Azure document webpage might aid you in making the right decision.

But no matter what the future might bring, one thing is for sure: SCDPM as a local on-premise entity is transforming more and more into a cloud based solution. Of course, when running on-premise or hybrid workloads, there will be a hard requirement for a small on-premise footprint. But more and more the logic, storage and management of it all will move into the cloud.

On top of it all, many backup options will be integrated more and more into specific services. As a result there won’t be 100% coverage offered by SCDPM or the Azure based backup services. In other cases there won’t be a out-of-the-box backup solution available at all. As a result third parties will jump into that gap, created by Microsoft.

A ‘shiny’ example is the backup of Office 365. Lacking by default and not in Microsoft’s pipeline, Veeam jumped into that gap by offering a solution made by them.

So at the end, the technical solution to your company’s BCDR strategy might turn into a hard to manage landscape of different point solutions instead of the ultimate Set & Forget single backup solution…

Coming up next
In the fifth posting of this series I’ll write about SCSM (System Center Service Manager). See you all next time.

Webinar: PowerShell Monitoring Management Pack

SquaredUp will present a webinar on the 19th of July in which they will release their PowerShell Monitoring Management Pack.

During that webinar the new MP will be demonstrated. The developers will take a technical deep-dive and show some examples of use cases for this MP.

With this MP we can put VB scripting behind us and focus us on the here, now AND future by using PowerShell workflows for SCOM monitoring!

And the price of the MP? SquaredUp is pretty clear about it: ‘…As part of our continuing commitment to the SCOM community we’re extremely excited to announce that we will be making a new PowerShell Monitoring Management Pack freely available to the community, available to download from our site and open-sourced via GitHub…’

Want to know more? Go here and signup for the webinar.

Wednesday, July 5, 2017

Cross-Post: Azure Stack Pre-GA Update

Mark Scholman posted an excellent article about the current status of Azure Stack, just before it becomes GA (General Available).

Since this article is an excellent write-up all about Azure Stack, I recommend anyone interested in it, in any kind of way, to read it.

Thanks Mark for sharing!

Azure Tip: How To Restore The Portal To Default

Bumped into this situation myself: I modified the ‘default’ Azure portal dashboard a little bit too much…

So I wanted to go back to the default layout. Took me some time to locate this option. When found I experienced a ‘duh’ moment. In order to save you the same embarrassment I decided to share this tip.

  1. When requiring to set the Azure portal default dashboard back to it’s original settings go to Portal Settings;
    image
  2. Hit the button Discard modifications. You’ll be shown this screen:
    image
  3. Select Yes. The Azure portal will freeze now for a couple of seconds;
  4. After the temporary freeze, the Azure portal will ‘restart’ like it’s the first time, including the Welcome screen:
    image
  5. Select the option you prefer and presto, the Azure portal default dashboard is back to it’s original layout.

Good to know when restoring default settings:

  • Your custom made OTHER dashboards won’t be affected. So they are retained;
  • The previously chosen theme will also be retained.