Any ideas for grouping multiple request prompts into the 1 -Eg. Create 10 VMs with different prompts

Mark_Wahlert

We have a number of requests from IT for requests like Create VMs, Decommission Equipment, etc.  These often need to be done in a group, meaning sequesters need multiple VMs created with differing attributes/prompts. Asking them to submit 10 requests for 10 VMs, each with 20+ prompts doesn't go down well, so does anyone have any ideas or solutions that address this scenario?

Workarounds we've used are larger free text prompts with some instructions for how to format. Eg. VM #1 - XXX, VM #2 - XXX, etc.
We are investigating:
1 -  a copy SR with prompts.
2 - RO that directs requester to a SharePoint Nintex form that has more workflow capabilities to possibly update an SR or create more.

Open to ideas.

Adam_Dzyacky

Before I jump into this, you mentioned there are some special attributes/prompts during the build process? If you're open to sharing, I'd be interested to know what they are. Perhaps there is some way of creatively automating them into the provisioning process?

Decom -
Conceptually has always sounded/felt easier since the items hopefully exists in the CMDB in some capacity. Hopefully I'm not stating the obvious that the kind of decom process I'm envisioning would be a Query Result of some group of X servers and you allow multiple item selection. Then the associated runbook (SMA/SCO) to the CR or SR that is submitted just grabs all of those related items and does something like:

• Retire in SCSM/Cireson Asset Management
• Move to some retired Active Directory OU (or just deletes it)
• Deletes it out of SCOM monitored devices
• etc. etc. insert your unique org processes here

I'm actually going through a bit of a build of this myself and still walking through a "what is the simplest, cleanest way to perform this." You could also do something like notify the custodian of the device...but I'm probably being over optimistic on that relationship existing (and no less consistently) for every device in your environment


Provisioning -
What I've started moving towards and getting right with is caring less about the individual hostnames of machines and more about the services they provide*. It goes without saying, heavily leveraging automation to either place these items in some correct OU, writing some kind of useful description in the machine, writing the SR in the AD attributes, or some kind of "flag" to take note of what the machines are since it can no longer be derived from the name. This strategy also somewhat implies that there is limited or Just Enough Administration to prevent people from accidently or intentionally manipulating these attributes inside of AD.

Whether you're in your own data center or someone else's (Azure, AWS, etc.) I would argue that you're really interested in providing a service (i.e. Service Manager, SCOM, etc.) and less interested in the names of the machines that run those services. In which case - machines become interchangeable, open to hot provisioning, and of course able to be entertained by this Request Offering idea.



*I will say that I'm entirely aware that the "who cares about names approach" is certainly viewed by some as a crazily progressive approach on VM provisioning, but I struggle with this a lot in the name of "keep the request simple" and no less in the way of "I wanted 13 SQL machines...shouldn't I just have some kind of integer along with a 'type' of machine and then it (SCO/SMA) just does the work for me?"

Adam_Dzyacky

Before I jump into this, you mentioned there are some special attributes/prompts during the build process? If you're open to sharing, I'd be interested to know what they are. Perhaps there is some way of creatively automating them into the provisioning process?

Decom -
Conceptually has always sounded/felt easier since the items hopefully exists in the CMDB in some capacity. Hopefully I'm not stating the obvious that the kind of decom process I'm envisioning would be a Query Result of some group of X servers and you allow multiple item selection. Then the associated runbook (SMA/SCO) to the CR or SR that is submitted just grabs all of those related items and does something like:

• Retire in SCSM/Cireson Asset Management
• Move to some retired Active Directory OU (or just deletes it)
• Deletes it out of SCOM monitored devices
• etc. etc. insert your unique org processes here

I'm actually going through a bit of a build of this myself and still walking through a "what is the simplest, cleanest way to perform this." You could also do something like notify the custodian of the device...but I'm probably being over optimistic on that relationship existing (and no less consistently) for every device in your environment


Provisioning -
What I've started moving towards and getting right with is caring less about the individual hostnames of machines and more about the services they provide*. It goes without saying, heavily leveraging automation to either place these items in some correct OU, writing some kind of useful description in the machine, writing the SR in the AD attributes, or some kind of "flag" to take note of what the machines are since it can no longer be derived from the name. This strategy also somewhat implies that there is limited or Just Enough Administration to prevent people from accidently or intentionally manipulating these attributes inside of AD.

Whether you're in your own data center or someone else's (Azure, AWS, etc.) I would argue that you're really interested in providing a service (i.e. Service Manager, SCOM, etc.) and less interested in the names of the machines that run those services. In which case - machines become interchangeable, open to hot provisioning, and of course able to be entertained by this Request Offering idea.



*I will say that I'm entirely aware that the "who cares about names approach" is certainly viewed by some as a crazily progressive approach on VM provisioning, but I struggle with this a lot in the name of "keep the request simple" and no less in the way of "I wanted 13 SQL machines...shouldn't I just have some kind of integer along with a 'type' of machine and then it (SCO/SMA) just does the work for me?"

Mark_Wahlert

Thanks @Adam_Dzyacky. Some good tips there for requests for new and getting rid of old VMs.

What about a situation for say multiple VPNs, where they can't be grouped like VM specs, each have the same prompts for locations, port speed, etc. but still it would make sense to keep in the 1 SR? 

We've tried a workaround whereby we state in instructions if you need more than 5, contact the service owner, then;

We use 5 sets of the same prompts (description, name, location, port, bandwidth, etc), each ending with "Check box for additional VPN" (Boolean prompt). 
I then set the layout conditions so that each additional set of prompts will only show if the check box for the previous set is checked. For the 5th set the last prompt says to contact the service owner (display only).

It's a little time consuming, mostly duplication but it seems to work well for up to 5, you can do more but it'll depend on your patience and how many prompts you can map to.

Another idea I think people have raised is a shopping cart, select 5 of the VPN request offerings, and it should let you update all 5 upon check out. 

Adam_Dzyacky

With respect to VPNs, Subnets, and all things Networking I've been having a rather ongoing internal discussion about it. So since you've presented the question, here's what I've been debating...with myself.

Single VM Approach -
If request is only for 1 VM, I need a Query Result of said items along with a manually created one of something like "I don't see my item here". Using Advanced Request Offering open some new inline flow for creating said network construct during the provisioning of the VM

Challenges/Notes:

• Does it make sense to allow the creation of a networking construct in a VM process? From a simplicity standpoint yes, but from a process flow - maybe? Is it possible that creating network constructs require their own process approval flow independent of a VM? Something tells me the networking team may want to know what's going on. If this is to be one request, the entire request is going to have to become very dynamic via SMA by dynamically creating PA, RA, and other RB activities at SR submission that conditionally exist based on the need for a networking construct.
• If I'm going to present networking constructs out, I need to get them from somewhere (i.e. SCOM CI Connector). But if I go this route, I won't be able to create instances (objects) in the CMDB as they are defined by SCOM. I'd have to create a wholly new class maybe? Perhaps the better way to solve this is to use an Enum List that gets updated on some regular basis. I don't like the enum route because i'll have to wait 24 hours for the portal to refresh (could be edited per Cireson documentation, but still). If I go the class/object route the portal would update in real-time but I'll need someway of creating those objects.

Multiple VM Approach - 
If the request is to be something like pick your number of VMs and then their type (i.e. "SQL", "IIS", etc.) then I have to assume a lot in the submission.

Challenges/Notes:

• Going this route I believe would simplify things because you could say "All of my SQL boxes are on this VLAN" or "All of my IIS servers exist on this subnet". What's more, just adding another qualifier in the request may help guide this even further such as "Is this for development, staging, or production?" By assuming these things, it eliminates the need to build out a huge (potentially unnecessary) process of approvals, notifications, etc.
• If these items can't be assumed you end up right back with the struggle of a 1 VM approach. Does the networking team need to know? Should this be done inline? etc.

General Notes about either approach:

Would this network change necessitate a CR to be created simply for house-keeping? That means the RB or some other RB has to creatively make an associated CR. Although now I'm now probably at the point of discussing organizational vs enterprise processes. Either way, it's not difficult but certainly just "one more thing" in the whole process


Specifically addressing and studying your "5 prompts" point the following question arises:

• If I had an integer of "7" as a prompt and a single Name, Description, Port, etc. fields - why not regex every single one of them so each instance is separated by a semi-colon, asterisk, or some other special character? Then you could have the runbook associated with this request just parse them out?

If you combine the above with an Advanced Request Offering the only thing you need to selectively show is corresponding fields for a regex that is matching a combination of 1, 2, 3, etc. So you maintain just the five prompts you listed, you still enforce validation pre-submission, and you map all of these to same fields on the backend request allowing you automate in a consistent way.