System Centre... playing with Service Manager
by, 30th November 2012 at 11:26 PM (8301 Views)
Ok, so I think people who follow my work often will know that Im a bit of a fan of the whole System Centre thing (yes - I know ive spelt System Centre properly, not the American "Center" that gets used everywhere!).
You see, Configuration Manager - formerly Systems Management Server has always been a winner for me; but the real power now comes if you extend the stort by combining the elements of the suite together. System Centre is designed so that its components share information with eachother - to give you a complete picture and management of your system.
Take this scenario...
A machine develops a fault, or a bit of software fails to install. Operations Manager sees the fault and records it. Service Manager picks up information from Operations Manager, and generates a ticket. The ticket generation is assigned a category by the rules set up in it, which in turn sets of an automated routine "Workbook", which could be to instruct Configuration Manager to push the software again - or rebuild the machine.
Neat eh... or scary depending how you look at it.
So, in this post, Im going to deal just with Service Manager. This nice little (well big) bit of kit is Microsoft's answer to ITIL, and it has to be said, theyve made a pretty good go at it too. To start with, you will think its a complicated beast. There are some great getting starting guides for it out there though. The bit I was most concerned with was how to integrate it into my existing procedures. You see, Ive had a helpdesk system for a while - Ive been a big fan of GLPI (www.glpi-project.org). So, its web interface was customised and built into our Sharepoint Intranet (I'll return to blogging about Sharepoint in the future); as well as having email submission and alerts.
SCSM has a web portal component... great! Bad... it usually installs its own Sharepoint instance and site collection. Not what we want here. I want to integrate it into my existing Sharepoint install. Oh, and just to top off the complicated-ness...this needs to work via TMG (formerly known as ISA)...
Theres a few gotchas with this process...and thats the point of this article.
To begin my journey, lets start with the Shared Services Portal or SSP. The SSP is fundamental, it’s not that difficult to install, but there are some gotchas. The blank Silverlight screen has been seen a lot - just try googling Service Manager Portal Blank. For me there were two main hurdles to setting this up, first was the whole "already having an existing Sharepoint", and second getting the SSP to work through our Forefront TMG server. I’ll walk through the whole process and hopefully it may help any out there needing to do the same.
OK, so a dead simple setup really; install Service Manager - followed by the Web Content part (on the same server), which plugs into the Service Manager’s SQL backend. Then, we need to deal with getting the Sharepoint solution (WSP file, for those who dont usually play with Sharepoint) out of the installation so that it can be instInitially getting internal users up and running, then getting external access working later on.
The basic structure of how you would usually install SCSM is shown below.
Now, the actual install for the main SCSM application and database is quite simple.
From the installer, you want the Management Server first; then you want the Web Portal. The first part is relatively self explanitory, the second - we need to be a bit more careful with.
1. Tick just Web Content Server
2. The usual Name, Organization, and the obligatory tick license agreement
3. Keep the installation location as default, unless you really need to change it.
4. The installer will check over your system. On the next page it will run through the pre-reqs, often warnings are for the SQL Management Objects or Memory - it can be a bit hungry!
5. OK, heres where things get a bit more complex. So that our external access will work properly (and Im assuming here that your Intranet login uses HTTPS  here) you need to set the port as 443 for SSL. You will also need to import your certificate for the content server (note - this needs to be the same certificate you are using on your external access TMG/ISA box).
6. Change the Database Server and Instance to point to the SCSM SQL server, and select the database
7. Enter the Service Account for SCSM and test the credentials
8. On the following pages make a choice for Customer Experience and Updates
9. Review selections, Install
This will have done the Web Content Server bit, but now we need to deal with the Sharepoint end, that actually gives the user interface. A full guide on this can be found at http://blog.scsmsolutions.com/2012/0...ng-sharepoint/
In summary though, you need to get the WSP from the install. This means going routing through the installation media to get it! Search for *.wsp and you should find it - it is called "Microsoft.EnterpriseManagement.ServiceManager.Por tal.SharePointSite.wsp".
Then, run the sequence of commands on your Sharepoint server...
1. Launch the “SharePoint 2010 Management Shell” (PowerShell)
2. To install solution run command: Add-SPSolution “c:\SMPortal\Microsoft.EnterpriseManagement.Servic eManager.Portal.SharePointSite.wsp” (where you have copied the wsp to the path C:\SMPortal)
3. To install solution run the command: Install-SPSolution Microsoft.EnterpriseManagement.ServiceManager.Port al.SharePointSite.wsp –GACDeployment
4. To activate solution run command (also you can do the same at Site Properties): Enable-SPFeature SMPortalSharePointSiteFeatures -Url http://portal where http://portal – full URL of the site collection where you plan to use SCSM web-parts.
Next up - a bit of web.config editing!
So that dd new setting named “SMPortal_WebContentServer_URL” and set its value to “http://webcontentserverort/ContentHost/ClientBin/” where webcontentserverort is name and port of prevision installed SCSM web content server. Note to protocol (http or https). Now, this is another cause of the blank screens. This path needs to match your external path followed by "/ContentHost/ClientBin/". Seems odd, but once we configure TMG, it will make sense. We are making it so that all the communication routes are always available throught one consistant path.
Over to TMG now...
We need an access rule, that publishes our /ContentHost path higher up than our main Sharepoint rule - otherwise the /ContentHost path will never be processed.
Create a new access rule in TMG
Now I needed to create a Web Publishing Rule on the TMG server to allow the bridging from 443 outside to 444 inside. Luckily for here the Silverlight web part uses specific paths, I can use these so as not to disturb my rule for the SharePoint web site.
1. Logon to the TMG server
2. Start-up the Forefront TMG console
3. Create a new Web Publishing Rule above the SharePoint web site access rule, and set the following…
4. Once these change were made the SSP worked internally and externally, all using the same URL and same certificate.
Total Trackbacks 0