1. You know what you want to achieve. I find that in many projects the technology team can get away with deploying a piece of software, scraping through a deployment, and ending up with something workable. This is not the case in System Center and IT Service Management. If you have not defined what you intend to deliver you will not be successful. You need to set definable goals for success that you can measure your progress against. This is called outcome based planning. In a proper scenario you organize ahead of the project, or in the first phase, what the exact outcome is. A few examples of that outcome could be, saving time in new user provisioning by 200%, deploying servers 50% faster, removing one escalation from the average help desk ticket.  A few posts which address entry points and goals are:

5 Reasons to Start with Business Services in Service Manager

System Center ROI and Orchestrator

Top 10 Production Experiences with Service Manager and Orchestrator

Workstation and Application Automation with Service Manager and Orchestrator

2. You know the measureable impact of your project. The most successful projects are the ones that not only have a goal defined, but know how to prove an ROI around their project deliverables. What will be the success that you will experience when your project is completed? Will the user provisioning process save your staff time and let you re-allocate team members to different deliverables? Will the server deployment process let you serve your customers better? Will the escalation process allow you to fix end user computing problems drastically faster? Find out the questions you can answer with the most impactful “yes” and focus on those. I find that what people *think* should be the focus of their project often is different than what will have the most positive impact to their business in the short term and set them up for long term success.

3. You have a reasonable timeline to achieve your goals and impact. Are you defining a reasonable timeframe for your project, or is the project best described as “trying to get the old tool out”. As much as I understand that removing the old tool is important for posterity sake, the most important goal is setting a reasonable timeframe to achieve the successes you’re looking to deliver. If you want to deliver a successful new platform that you won’t replace later, you need to focus on process and ROI vs. tools and technology. After you’ve defined your goals, now define how long it will take to get there with the resources you are willing to commit to the project. In my experience, is you are going to compromise time and features tends to be a better place than quality.

4. You have communicated your timeline and goals effectively to the project team and beyond. Is your strategy clearly articulated and available for people to read? Is it buried in a word document somewhere that is 100 pages long? I start almost every strategy engagement with a roadmap using PowerPoint. I find that by clearly stating the goals and direction it is much easier to rally the troops toward an outcome that I’m looking for, especially if they see the direct ROI in the project and where their future has the opportunity to go.

5. You have the skills and time allocation to execute. Are you trying to accomplish a project without the necessary skills and people? I find that in addition to outside help, many companies underestimate the changes necessary for their own internal teams that are required to achieve true process and technology transformation. The good news is that almost any company can execute on this with help, but you need to be willing to invest in your people, to change roles, and to allocate time to achive success.  Here are a few good resources to kick start your knowledge:

System Center Survival Guide

Microsoft Virtual Academy

I find that service management engagements have an opportunity to drasticly transform how an IT department delivers. It can raise the quality, responsiveness, and management of everything that IT brings to the business. Stay tuned for more in this series…

Cheers!

Nathan Lasnoski

The post 5 reasons System Center Service Manager / ITSM projects are successful : SCSM Getting Started appeared first on Concurrency, Inc..

One the most important data elements that need to be consistent are dates and times.  Fortunately for us, all dates and times in the Service Manager database are stored in UTC format.  Let’s take a look at an example.

Being in the lovely state of Wisconsin, we live in the (UTC-06:00) Central Time (US & Canada) time zone.  During Daylight Saving Time, the offset is actually UTC-05:00.  Let’s use an Incident for our example.

As you can see, IR 6160 has a Created Date of 5/9/2013 10:31:19PM.  That is the actual time (in Central Daylight Time) I opened the Incident.

If we look at the DWDataMart DB, we will see that date stored as UTC (Since our offset is -5:00, to get to UTC, we would need to add the 5:00 back in, thus making the new time 5/10/2013 03:31:19AM

And we also see this same date in the operational CMDB.

So how come you don’t see this time in the console? The Service Manager console is programmed in such a way that when you view any dates or times, they are converted to the correct time zone of the machine from which you are viewing the data.  So if you have a console opened in sunny Bell, California, it will look at the UTC offset (which in that case is -08:00) and covert it properly in the UI.  Pretty cool huh?

So why do we care?  This really comes into play as you start to create/configure Orchestrator automations, PowerShell scripts, custom reports and my favorite, the CSV import.

I like to use the CSV import to either create/update some custom properties being synced over in a custom connector or to bulk import data from another system during a migration. Either way, all times in Service Manager are stored in UTC format, even in the CSV import. So if you wanted to import the date 01/01/2013 12:00:00 into your database and had a line in your CSV that said 01/01/2013 12:00:00 (or even just 01/01/2013 for that matter), it will interpret that as already being in UTC time.  So when you open it up in the console (and your offset is -06:00 for example), the date will actually read 12/31/2012 6:00:00PM.

I hope this helps anyone curious about why dates and times are stored the way they are.  

Until the Whole World Hears,

Christopher

The post What Time Is It? – How Service Manager Stores Date and Time appeared first on Concurrency, Inc..

Discover Azure Infrastructure-as-a-Service (IaaS)

Leverage Microsoft’s cloud-based datacenter. Build hybrid services that take advantage of what you already have while enabling new innovation in the cloud. Run Active Directory Federation Services (ADFS) in Virtual Machines to sync with on-premises identities for single sign on.

See what Windows Intune can do for your organization

Manage PCs and multiple types of mobile devices in one unified solution, either through the cloud or by extending your existing on-premises infrastructure. Give employees access to the resources and applications they need, on the devices they choose, without increasing complexity.

Explore the benefits of Microsoft StorSimple

Microsoft StorSimple securely and transparently integrates the cloud with on-premises enterprise storage through a single solution that delivers high-performance tiered storage, live archiving, and cloud-based data protection/disaster recovery, reducing costs by up to 80 percent compared to traditional enterprise storage.

The post Microsoft Hybrid Cloud Event – Milwaukee appeared first on Concurrency, Inc..

Don’t Synchronize Null Values

In the connector configuration you can select to synchronize, or not synchronize null values.  I find in many configurations of Service Manager the connectors are configured to synchronize null values and often end up fighting with each other.  In some cases SCCM synchronizes a blank value whereas Active Directory synchronizes a populated values.  This causes the configuration item to be modified every time the connector runs.  Here is an image of what I’m talking about:

Remove DCM Workflows

A series of workflows can be disabled which will drastically improve performance if not used.  An example of a workflow in this context is Desired Configuration Management.  If you aren’t using DCM, or believe you are impacted by this performance problem, here is the method to disable it:

Disable DCM Workflows in Service Manager

Sync What You Need

It might be tempting to turn on every configuration item and operations manager class to synchronize into your CMDB.  If you scope your connectors to synchronize only the objects you want, in smaller quantities, you’ll find your connectors will complete faster and you won’t be synchronizing as much data that you aren’t interested in.  If you want to synchronize a large amount of data you might be better off separating it into smaller connectors, or even using a custom connector.  Here is a great post on synchronizing variables you might need that aren’t in the default connector: Sync Other Properties to Service Manager using Orchestrator

Active Directory Target

The target of the Active Directory domain controller for the domain will often change when synchronizations occur.  The connector uses the USN ID to determine the next transaction to synchronize.  If you can, use DNS to configure Service Manager to use the least number of domain controllers possible so you aren’t having to re-synchronize data you’ve already reviewed.

Scheduling

The Active Directory connectors can be scheduled to run during off hours, which for most organizations (with exception of 24 x 7 global organizations) is an easy solution.   You can either configure this in the XML or you can configure Orchestrator to turn on and off the connectors on a schedule.

I hope this helps you out!  If you’d like to watch the full MMS presentation Configuring Service Manager for Performance and Scale, you can find it here: Service Manager Performance and Scale

Nathan Lasnoski

The post System Center Service Manager Scalability and Performance Tip: Connector Configuration appeared first on Concurrency, Inc..

1.  From within the Orchestrator Runbook Designer, create 2 new Runbooks.

2.  In the first Runbook, add the appropriate activities so you have something like the screenshot below.

3.  Lets focus on the top branch first.  This branch accounts for Analyst Comments added through the out-of-box function in the General tab.  Although you don’t have to configure them differently, I decided to do so since the Watcher list is not visible on the General tab.

Monitor Object
Here we have an object monitor looking for new Trouble Ticket Analyst Comments.  Once the Runbook finds one, it will start processing through the other activities.

Monitor Object Top Branch
If you recall from the previous post, we were setting the Display Name to “Watcher” if the Analyst Comment came from our custom control.  If you use the out-of-box control, the Display Name is set to the GUID of the comment.  So to determine from where the comment came from (the General tab or our custom control), we check for the word Watcher in the Display Name.

Rest of Activities
The rest of the activities are pretty self-explanatory.  We get the related Incident and then get the Assigned To User.  We then do a quick look-up in Active Directory (By Distinguished Name) to the get the user’s email.  We then send the email.

4.  Now let’s configure the bottom branch, which accounts for comments added through our custom tab/control.

Get Incident
The first few activities are identical as the top branch.  The only difference is we now look for comments where the Display Name DOES equal “Watcher”.  We then get the related Incident.

Create File
In this activity, we need a place to store all of the email addresses the comment will get sent to.  This allows us to update the comment with everyone it got emailed out to.  In theory, you could add any data about the user you wanted to the comment, but I just chose to add the email address.  Here we are creating a new text file to store this info.  We use the comment’s GUID as a filename to keep it unique.

NOTE:  When it comes to “global variables” in Orchestrator, best practice is to use a Runtime Database.  Perhaps in future blog posts I’ll show you how you can set this up, but for right now, text files will do the trick.

Invoke Analyst Comments 2 Runbook
We now run a sub-Runbook that will actually do the emailing.  This Runbook is shown below.  We pass two data elements, the Comment GUID and the Incident GUID.

Using the passed GUIDs, we get the Analyst Comment and the Incident.  Next, we get all the users added as a Watcher and the Assigned To User.

We then run a PowerShell script to get the user’s email address.

The rest is pretty easy.  We run an Append Line activity to add the users’ email address to the file we created in the parent Runbook.  We then get the Assigned To User (merely for adding their info to the email) and send the email out.

Run .Net Script (Parent Runbook)
After the sub-Runbook runs, we now run a PowerShell script that loops through each line in our text file and builds the $Desc variable with all of the emails the comment was sent to, one email per line.  We then run an Update Comment activity that updates the comment to be the $Desc variable, which contains both the comment and the list of email addresses.  Lastly, we delete our placeholder text file.

And that’s all there is to it!  That concludes the walkthrough of how the Service Manager and Orchestrator Ticket Emailing Engine is built.  Have fun!

Until the Whole World Hears,

Christopher

The post Service Manager and Orchestrator Ticket Emailing Engine – Secrets Revealed Part 2 appeared first on Concurrency, Inc..

In this post, I am going to walkthrough how this solution is built.  For demonstration purposes, I will just show an IR, but this solution can be extended to work with other types of Work Items like Service Requests and Problems.

1.  First we need to extend the Incident class to include a new property called Message and a new relationship called IncidentHasWatchers.  The relationship Target is to the Active Directory User Or Group class.  If you are unsure of how to do this, there is a plethora of examples on the web that can show you how.

2.  The heart of the solution lies in the following post.  It describes how instead of building an entirely new form in Visual Studio and importing it into SM, we can build custom controls and add them to out-of-box forms as customizations.  Using this technique, the possibilities are truly endless.  To build the Emailing Engine, I downloaded the solution mentioned in the post and added the code I needed.  You can download the full Emailing Engine solution here.

4.  Once you have downloaded the solution, we can open it up in Visual Studio.  There are two main files that make up our custom control, the XAML file and the C# code-behind file.  The XAML file (pronounced “zammel”) is where the visual elements of the control get created and configured.  You should already have a project looking similar to the below screenshot.

5.  The C# (.cs) file is where all the main code-behind lives.  We can tell the XAML file that when a change is made to a control, execute some code in the CS file.  A basic example of this is a button click.  We can configure in the XAML code that when our button is clicked, it executes a block of code that is found in the CS file.  You should already have a project looking similar to the below screenshot.

6.  The most important part of our solution is found in the method that is executed when an analyst clicks the Send button.  Here it is and described by color group.

Red:  We get the AnalystCommentLog class and create a new object.

Orange:  We set some variables based off of what the user has entered.  We set the user’s message, create a new unique GUID and also determine if the user has selected the Private checkbox.

Green:  We update our object with the proper values.  One thing to note here is that on the DisplayName, it is being set to “Watcher”.  This gives us the ability to track action log comments that came from this control.  We’ll see more of this when we get into the Orchestrator Runbook.

Blue:  We then use the IDataItem interface to convert the object we created in the Red step from an Enterprise Management Object, to an IDataItem.  We can then use that to save it to our form.  The “AnalystCommentLog” towards the bottom is the alias of the type projection the form is pointing to.

Purple:  Lastly, we clear out the Message textbox.

7.  Following the instructions from the post in Step #2, we can (1) Add our control to the existing out-of-box Incident form, (2) Seal it and create a Management Pack Bundle, and (3) Import the MPB into Service Manager.

8.  At this point, you should now have a fully functioning solution.  When you add some text to the Message textbox and click Send, a new comment is dynamically added to the Action Log.

The last steps are to configure Orchestrator to send the emails.  Stay tuned for Secrets Revealed Part 2 where we’ll see just how that is done.

Until the Whole World Hears,

Christopher

The post Service Manager and Orchestrator Ticket Emailing Engine – Secrets Revealed Part 1 appeared first on Concurrency, Inc..

The recording is below:

You can also find it on the Microsoft MVP Pro Series Blog here, as well as other speaker sessions!

http://blogs.technet.com/b/wincat/

Nathan Lasnoski

The post Building Workstation and Application Automation with Service Manager and Orchestrator appeared first on Concurrency, Inc..

I’ll start off with a basic example of “home plumbing”.  If I was in my kitchen and wanted to get a drink of water, all I need to do is walk up to the faucet and turn it on.  It then fills my cup and I turn it off.  It is totally intuitive, so much so that even my three year old can do it.  I (or she) requires no knowledge of home plumbing or complex skills.  However, the “magic” of the faucet is complex under the scenes.  In my house I have a well, which brings water into the house, then delivers it to a holding tank, then goes through the water conditioner, into the water heater, then to the faucet.  I’ve taken a stab at home plumbing from time to time and even though I might be able to make something work, it is neither well executed nor normalized with the professional plumbing community.  The key point here is that in order for the complex process to be useful to me, it needs to be easy and require next to no training.   If I were to take this example as an analogy for System Center, the faucet is Service Manager and the end user experiences (such a SCCM software center), the plumbing is SCCM, SCOM, and Orchestrator.  

I was listening to a talk that Jeffery Snover gave the other day and he mentioned an interesting equation.  Scale + Complexity > Skill.  The general idea is that in order to scale something it can’t require more than commodity knowledge.  In other words, you can’t hire enough smart people and have them act in unison to scale a process well.  This concept is well realized in the service management space and I’ll describe some of the circumstances in this post.

Let’s take an example of application deployment.  If I were to desire application packaging and deployment to be standardized and rapid in my organization I could (1) train a whole bunch of people to perform a process from a well written procedure,  (2) I could build a self-service request and automation to deploy the application programmatically, or (3) do nothing and don’t install software (not really an option).  In a smaller organization you might be able to get away with manual installations with a procedure, but I think the person performing those installations would get a little sick of it.  In the case of a large organization, manual installation cannot be scaled and normalized at the same time.  In the case of using an automation I drastically change the context of using and deploying applications.

In my example, here is how an IT person or an end user deploys an application:

You’ll note that behind the scenes I have a lot of complex things I want to do.  I have the installation check the software relationship, add the user to the collection, refresh the client machine, and process an approval.  This complexity allows the SCCM administrator to be happy as the environment he built is clean and well organized.  It also makes the IT end user happy as the deployment experience is really simple.  So simple that I could literally hire a person today and have them trained in less than 5 minutes.  A side effect of using self-service is that the user doesn’t require special permissions in the application.  They only require access to the portal.

In your organization I’m certain there are opportunities for this same kind of approach.  Think about any process where getting the right information, the first time, and automating a process would provide clear payback to the business.  Articulate what he payback is as an ROI and determine if it is worth tackling.  In most cases clear business value is very easy to come by.

Cheers!

Nathan Lasnoski

The post What home plumbing taught me about self-service, Service Manager, and Orchestrator appeared first on Concurrency, Inc..

The role of Data Protection Manager: DPM is the backup tool for all things Microsoft, protecting both the server infrastructure and the client environment. Data protection manager includes application and virtual machine backup, and allows custom add-ons for backups of mobile devices, client management devices, and different types of documents. Backups can be made to disk, tape, or cloud.

What’s new in SP1? New features in Service Pack 1 include support for Windows Server 2012, integration with Azure storage, and the ability to backup newer Microsoft tools such as SharePoint 2013, Exchange 2013, ReFS, and SQL 2012 with AlwaysOn.

The post Data Protection Manager 2012 SP1 [Video] appeared first on Concurrency, Inc..

PowerShell interprets single quotes (‘) very differently from double quotes (“).  Although I will not cover all of the differences in this post, what we do want to mention here is that if you use double quotes and your string already contains a double quote (“) in it, the script will most likely fail.

Let’s consider the following scenario to better understand.  We have a Service Request that is created via the portal that asks users to select new hardware/software they wish to purchase.  What we want to do is add some of the data to the Description field.  Using the Carriage Return technique, we have a PowerShell script that looks like this:

Here we are setting the $Desc variable to contain text about who the request is for, a list of all the catalog items selected and the Notes from the SR, all on separate lines.

Notice how the Published Data “Notes from Get SR” is encapsulated within double quotes(“).  99% of the time, this setup will work just fine.  But what happens if one of the catalog items selected is called (22″ Monitor).  See the issue here?  When we use double quotes around this string and the PowerShell activity sees the extra double quotes, it fails and causes the entire Runbook to fail.

So how do we fix this?  Super easy actually.  All we need to do is enclose our Published Data variable within singe quotes(‘) like shown below:

Single quotes in PowerShell are interpreted as strings, even though they may contain special characters.  So in our 22″ Monitor example, the script works with no issues.  As a general rule of thumb, you should use single quotes, but I recommend you take the time to study a bit on the differences between the two because as you script more things in PowerShell, you will find yourself needing to use both of them depending on the situation.  I hope this helps.

Until the Whole World Hears,

Christopher

The post Using Quotes in Orchestrator PowerShell Activities appeared first on Concurrency, Inc..