I’ve started my new job at Microsoft as a Senior Consultant for Orchestrator and SCSM so I hope to have many new adventures ahead and many new lessons to learn and share. During the transition I might have to slow down a bit on the posts till I get acclimated but hope to soon have them flooding in. With Microsoft’s backing I hope to expand my knowledge to even greater heights. Exciting times ahead. Wish me luck 🙂
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.
Welp, the storage crashed on my ESX server so I lost my lab and wasn’t able to restore it from backup. Oh well, at least I can reconfigure everything to squeeze more performance out of the iscsi luns. It might be a little bit before my next helpful post so stay tuned. Still have several awesome projects to post up.
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?