So I’m in the process of upgrading my lab to System Center 2016 and decided to do some write-ups on some of the issues that I have ran into during the process that might help some of you out there.
Sorry for the slow posts. This new job is no joke.
Here is a pretty easy one that will be invaluable to your company and provide insight to what is going on in IT. This is a dynamic SharePoint change calendar that will show real time changes and what stage that change is in depending on the customizations you have made to the change process in SCSM. Continue reading “Dynamic FSOC Calendar using SharePoint and Orchestrator (Updated)”
Everybody has those systems that wont directly integrate into SCOM for some reason or another. Usually due to no management packs available for that system or the 3rd party management packs are just too expensive for your company ◔_◔. Well I have a solution for that.
We are going to go back and revisit the datawarehouse article one more time. You might be saying to yourself, man that was very helpful but there are so many steps, and I have do this once a week, at least, and I have to blah blah blah…that’s why you get paid. Stop complaining! I’m kidding, I said all that as well. So I automated the process, and I’m going to share it with whoever stumbles across this page, ’cause that’s just the type of guy I am ;). Continue reading “SCSM Datawarehouse Jobs Failing “Automated””
If you haven’t heard of this tool I highly recommend you download it now. It’s called Orchestrator Health Checker and it is an invaluable tool to keep an eye on the health of your Orchestrator servers. You can find this tool hear. I wont go into too many details since there is quite a bit of information already listed but one issue I’ve always had was getting the Start and Stop Monitor buttons to work properly.
Are you tired of dealing with orphaned runbooks every week, filling up your available slots and causing runbooks to spill over onto the secondary runbook server? Ideally you should find the root cause of these runbooks orphaning. In our case it is due to our backup software taking the servers down briefly and causing the runbook server to lose connection to the database. We cant stop backups for obvious reasons but the next best solution is to let Orchestrator fix itself. You can download the entire project below.
It’s not always required to have a Review Activity or Manual Activity for a Service Request but you might have noticed that if you don’t have those then the complete button can take some time to appear for the technician to close the Service Request. When your techs are on the phones constantly and working multiple sessions this can become an annoyance. All they want to do is track the call in the ticket and move on. How about allowing them to track that call, save the ticket and move on to the next and have that ticket close itself?