Today I came across a nice article on Service Manager and Gartner magic quadrant. Enjoy.

https://www.cireson.com/business/why-is-microsoft-system-center-service-manager-scsm-not-on-the-gartner-magic-quadrant/#

Configuration Management Database (CMDB) is a central repository for all the configuration items in your Service management solution and requires maintenance to keep it up to date. If you have lots of Configuration items (CI) where there is no automated way to update the configuration, your CMDB becomes outdated and useless. Service Manager comes with connectors to import CI information from Active Directory, Operations Manager, Configuration Manager and Virtual machine Manager that makes updates a whole lot easier. You can fill-in your CMDB with all this information in a very short time and keep it updated regularly.

Keep in mind the following when deciding what to import into Service manager:

• Import items that can be updated: Do not bulk import items manually unless you have a compelling reason. Rely on Service manager connectors to import and keep your configuration information up to date. You can use CSV files to import new objects to Service manager but you will need to update the objects regularly manually using this method.
• Not all configuration information is useful: Operations manager can monitor devices that have SNMP connectivity such as printers and you can import these objects as CI’s to Service Manager. However just having the technology for updates does not mean you need to import it to Service Manager. Balance the benefit of having the object with increasing the size of your Service manager database.
• Change in configuration is the key: Rule of thumb for import is to check if configuration of the desired object needs to be tracked. ITIL is all about managing risk and change brings risks. If you have a class of objects that you need to track change in configuration, it might be considered as a candidate for import.

Not all items that can be imported into Service manager brings value. You need to write down the pros and cons and decide accordingly.

• 
  Writing a script is not a onetime event. A
  scripting solution is brittle and breaks easily when environment where scripts
  are running changes. Writing scripts that handles most of the possible exceptions
  is not an easy task and requires a lot of experience.
• 
  Scripting is a development skill. You need to
  keep people in your team to write and maintain scripts. Different products used
  to have different scripting languages but thanks to Powershell, it is getting
  standardized over most of Microsoft products.

Microsoft has recently released System Center 2012 Orchestrator
which is used to create workflows (called runbooks) in an easy way. Basically
it helps IT pro’s visually create linked commands to do automated tasks. It can
communicate with other systems through Integration packs and can be very
powerful tool to fulfill your automation needs. If you need more information on
orchestrator, you can start here.

The problem with automating tasks is not about the tool that
you are using. It is related to the processes. When you are doing a task
manually, it is easier for somebody else to follow on what you are doing and
when. If something goes wrong, you can search for event logs on who logged on
to systems and ask questions on their actions. However if it is automated
(either through scripting or orchestrator) tracking what went wrong becomes
much more difficult. In order to ease have a smooth operation, you need to have
a more structured approach. For example you need to have a change a request for
the automated task (such as cleaning up old computer accounts from Active
Directory) recorded together with the results so that you can search for it later.
Keeping these kind of records were a manual task in the past. However
orchestrator has a Service manager Integration pack that you can do these kinds
of requests automatically.

The best way to implement automation in IT systems is to
have Service manager 2012 to keep records of what operations are being done and
even providing capabilities such as approvals to keep it under control. For
example you can have a scheduled task in orchestrator that searches for old
computer accounts in Active Directory weekly. If it finds such accounts it will
create a change request in Service manager which goes through standard approval
processes to IT administrator and after this approval a runbook in Orchestrator
is triggered to actually delete the accounts and results recorded in the change
request. You would be able to see reports on change requests on when deletion
of certain computer accounts were requested, who approved it and when it was finished.

Using System Center 2012 Service manager together with
orchestrator will save you lot of time without losing control of your IT
environment.

In the second part of this series I provided details on how
to check for inconsistencies on user attributes and set for UPN which can be
found here.

In this part of the series I will give you details on how to
setup the coexistence. So here are the steps to configure coexistence:

• 
  Conditional
  Forwarding: As you have 2 different forests you will need to have DNS name
  resolution between the domains. You can use DNS conditional forwarding feature
  to do this.
• 
  Trust
  relationship: some of the tools that would be needed for migration (Hint
  ADMT) will need Windows trusts to be configured between the 2 forests. You will
  also need to configure Windows trusts for cross-forest availability.
• 
  Directory
  synchronization: After you start migrating the users, you need to make sure
  users are available on both sides. The recommended approach is to use FIM to
  synchronize users, distribution groups and contacts. While you are configuring
  you need to plan for migrating the users through your migration planning and
  will need to configure the new object provisioning through FIM. (Ex: What will
  happen when a new user is created in old forest during coexistence)
• 
  Control
  panel: remember our scenario. We are moving only Exchange functionality to
  the new forest. In this case you might consider using control panel to manage
  Exchange properties of the users. If this is the case you might have to do
  configuration on your Control Panel.
• 
  Coexistence
  Server: In order to migrate users and provide mail flow you can use an
  Exchange Server 2010 in the old forest. This will provide you with the new
  mailbox replication proxy functionality. You would also use this server
  together with the Exchange in new forest for providing availability services in
  cross-forest migration scenario. You would need to have certificate installed
  on this server that would be trusted by the new forest Exchange servers.
• 
  E-mail
  address policies: In order to flow mail between two organizations you will
  need to configure secondary e-mail addresses for each side.
• 
  Send and
  receive connectors: These will be needed on both sides to enable mail flow
  between 2 Exchange organizations acting as a single organization.
• 
  Cross-forest
  Availability: During mailbox migration you may want to have each side of
  your Exchange servers to be able to query availability information for
  respective recipients. For more information have a look here.
• 
  Auto
  discovery: You will need to configure auto discovery services so that one
  you start migrating the users, they will be able to reconfigure themselves for
  the new forest. Please keep in mind that this will work for seamlessly for
  Outlook anywhere and ActiveSync but if you configure the coexistence server as
  your Internet facing CAS servers you will only get a redirect, which means
  migrated users will be prompted for authentication on new servers. You can use
  an Access gateway solution to provide seamless redirection when the mailbox has
  been moved and they are accessing through OWA.

These are the basic steps you will need to do configure
Coexistence between 2 forests.

In the second part of these series I will provide more about
handling the transformation to UPN. When you decide to use e-mail addresses for
your UPN, you will need to make sure that you create the UPN from the used
e-mail address of the user. Although this may seem trivial it may not be.
Generally you will want to create the UPN from user’s alias attribute and the E-mail
domain. However alias attribute is populated only once during the mailbox
creation and administrator can change the mail address of the user after it has
been created. In order to identity these account we need a script to compare
these values. The script will basically do the following:

First read all the mailboxes in the organization and loop on
them. Please note that you will need to put resultsize unlimited parameter to
get the whole picture.

get-mailbox
-resultsize unlimited | foreach{

Then you would need to get the e-mail addresses of the user
inside the loop.

for ($i=0;$i -lt
$_.EmailAddresses.Count; $i++)

Once you have the list, you will go through the list looking
for address prefix SMTP which will give you the Primary SMTP address (Secondary
ones will be given by smtp). Some of the users may have empty Email addresses
so you need to check that condition also

$address =
$_.EmailAddresses[$i]

$a=$address.AddressString.ToString()

if
($address.PrefixString -eq "SMTP" -and $a.length -gt 0 -and $a.indexof("@")
-gt 0)

Now that you have found the address you need to store it to
be used after the loop.

$Primary=$a.substring(0,$a.indexof("@"))

Now lets check if this matches the alias attribute

if
([String]::Compare($_.Alias,$Primary,$True) -ne 0)

You will generally have the necessary plumbing to write the
results into a log file for easy consumption. The complete script can be found
as an attachment to the blog. The script is provided as is without any warranty
so use it at your own risk.

After you have identified these users you will need to
correct the alias attribute according to the primary SMTP address attribute.
The script for this is left as an exercise to the user.

You may be asking why we were so diligent about correcting
the alias attribute instead of setting the attribute through a script. The
reason is simple; writing scripts to touch large number of users requires
careful testing.

 So now we need to do
the following:

• 
  Create
  UPN suffixes: Creating UPN suffixes can easily be done through a single
  line of PowerShell. See here
  for more details.
• 
  Populate
  UPN prefix for each user: You can use ADModify tool to do
  this.

After this tasks your users will be able to use the same
e-mail address as their logon names.

Let’s take a hypothetical organization running Exchange 2007
which wants to move to Exchange 2010 in a new forest. For the sake of argument
lets say customer only wants to migrate exchange functionality to the new
forest and the old forest will remain where Exchange will be uninstalled. When
the number of clients involved is large, the mailbox move process can take
longer than the organization can tolerate downtime and coexistence is needed.
Coexistence can be defined as where you have 2 exchange organizations in 2
different forests and it acts like a single organization. Here are important
points to consider for kind of migration:

• 
  Mail
  flow: generally mail flow to and from Internet is done from the old
  organization during coexistence phase and mail between the organization is done
  with connectors in between.
• 
  Mail
  Access: For OWA users this will depend on where the mailbox is hosted at a
  given particular time. Exchange can provide redirection to the new environment,
  more on this later. For Outlook anywhere and ActiveSync users Autodiscover will
  need to be used in cross-forest configuration. In order for autodiscover to
  work you will need to have Outlook 2007 as a minimum on clients.
• 
  Availability:
  During coexistence you need to be able to query free/busy information. Exchange
  2010 supports several methods to get this information.

In order for these functions to work, you need do analysis
on source forest:

• 
  Single
  sign on: During coexistence you will need an entry point that can connect
  to both forests and would receive credentials from clients only once.
• 
  Account
  names: If customers are using Domainname\username format to logon, this
  will need to change when Exchange moves to the new forest. One way to solve
  this problem will be to use UPN. Users accessing old forest can start using UPN
  and the new forest will also have the same UPN but different forest name. Generally
  you would want to have UPN the same as the e-mail of the user.

This part clearly shows you need to have a lot of
preparation before you do the migration. We will focus on more details in later
series.

So when does this become interesting? Recent advances in technologies provide lots of systems to be aware of their surroundings. For example your Windows 7 phone has cameras and accelerometers and can detect its orientation in your hand. With the help of software you it can tag the picture with the date/time and place (through GPS) when you are uploading it to a web site. So you are in a foreign country and you don’t know the language. You point your phone to the sign and in real time you see the same sign through your phone in your own language. There are actually prototypes for these applications for other mobile platforms that are impressive. So basically we are connecting sensors from all around the world to Internet. (Information on RFID sensors can be found here and development information can be seen here) I just want to stress how powerful this can be. Obviously there are privacy issues that needs to be taken care of but that’s a different topic.

Microsoft announced Kinect for Xbox 360 a while ago. There have been lots of articles on how it would change the gaming experience.(One example can be seen here) Apart from being used as a controller for games, it became very popular for other uses. There have been different projects (Examples can be seen here, here and here) all around the world for using Kinect for never before thought purposes. The reason for this popularity was that we had all necessary components except the software to tie everything together. Now that we can use the power of software to get information from the data coming from the sensors, a whole new world begins. I am sure we will see these kinds of solutions embedded more and more into our lives.

Just to give you a few examples on potential applications, you would see Intelligent TV sets. It will open when you sit in front of them and you would be able to control them through your hand gestures (Netflix on Xbox 360 can do this Today), no searching for the lost remote controls anymore. In the near future except for high security areas, we will start seeing face recognition for access control. That means no use of passwords or maybe even keys for some uses. So you may have a home system where there will be a log of every major event. Your family members entering home, going out. If they are using an Internet enabled shoes for jogging you will see how fast they are going or even if they need help.

So Internet of things is about to become reality for the majority and will change our lives in ways you will never have imagined.

Microsoft has a service management solution based on System Center Service Manager. Although you might think it is a new product actually it has been in the works for quite some time and has been rewritten several times before releasing as a product. There are several good resources around how SCSM is aligned with MOF and processes but the real reason behind using these type of solutions is to keep track of all service management activates and creating reports on them. For example if you deploy a service pack to your servers and some of the servers do not boot, the first question you would ask is why didn’t we see this during our testing? So who did the testing, when did it happen and what was the result and where is it now? That’s where you need the service management or update management to be specific. You need a solution just like SCSM that will record a need for change (apply Service Pack) create and record a workflow of events (Approve for testing, assign to a person for testing and recording results, approve for pilot servers, record results and approve for distribution to all servers) so that you can come back later to see if everything was done properly.

So far, what I have told is not interesting for some. I am just imposing more paperwork to you who are the already busy doing work. However there is a lot of maintenance work that a datacenter admin would need to do in terms of checking files, running scripts etc. What if there is a wizard behind the curtains that can read the change requests, do all the maintenance tasks and put the results back to the change request. That wizard is Opalis. Opalis is a workflow engine that has integration packs with lots of other systems and can read events, objects from them, act on them and return the results back to the other systems. It is like writing scripts without entering a single line of code.

Let’s talk about an example. One of the common things a domain administrator will do is search for old computer accounts in the domain and delete them. This has to be done regularly in order to keep your Active Directory clean. From a service Management perspective this is a process that needs approval. You can have a policy in Opalis that will trigger every month and run a script to search for old computer accounts in the domain and create a text file with computer names in it. Then it will create a change request in Service Manager from a template you already have for this process. Service Manager will record the request and trigger a review activity for the admin that will send you (the Domain Admin) an e-mail saying that you are expected to approve the deletion of old computer accounts. Going to Service Manager, you check the list of computer names and approve the request. Opalis will happily see that can trigger another policy to run a script to read the file and delete the computer accounts in the domain and put the result of the activity in the change management request and if successful will close the request automatically. Now that makes everybody happy. IT management can view these change management activities in their reports and domain admins do not need to remember running these scripts.

Service Management can actually make people’s lives easier when SCSM is used together with Opalis.