Reaching out to anyone who has SMA and WAP installed in their environment

Eric_Krasner

I am trying to get SMA up and running in our System Center environment and was not planning to install WAP.  However it has become clear that to manage and troubleshoot SMA runbooks, WAP is still required.  If this is the only reason I am installing WAP, is there any reason not to install all of it on one server in express mode?

Tom_Hendricks

There seems to be no issue at all with installing WAP on the SMA management server.  Both seem to be light on resource usage, especially when compared to SCSM.

WAP is nice and convenient, but I would hardly call it necessary.  In theory, you could recreate nearly all of its dashboards in the Cireson portal by querying the SMA DB, and you could perform all the WAP functionality with a combination of TFS release integration, the SMA Toolkit in Powershell ISE, and some creative use of catalog forms.  Or any number of other interfaces.  SMA can be controlled via PowerShell and via web service, so it is quite versatile, but BYOI (bring your own interface).

Note that if you are installing WAP, it is possible to disable all the (visible) modules other than "Automation" in the admin portal, if you like.  You also only need to run about 3 of the 13 different sites that WAP installs, if only using it with SMA.  Every update sends you back to out-of-box config on the module visibility and which sites are active, so you'll want to script that or have something to push from TFS/Git/etc. after updates to WAP.

Tom_Hendricks

I have not found any issues with it whatsoever.  Neither is anywhere near as much of a resource hog as service manager or SCOM, so your SQL server can be modest by comparison.

Tom_Hendricks

@Eric_Krasner, here is the file that you would need to edit:
[IIS Site Root]\InetPub\MgmtSvc-AdminSite\Manifests\UiManifest.xml

Look for <extension> nodes, and note the "name" attribute, which will tell you what each is for.  Just comment out (using <!-- and -->) the entire node and its contents for anything that you don't want to see, such as "PlansAdminExtension" or "SqlAdminExtension."  Note that some extensions need to be kept even if you do not think you are using them, such as "AppExtension," "MonitoringExtension," etc.  The one that displays SMA is called "AutomationAdminExtension."

Your changes will not be visible until after you recycle the MgmtSvc-AdminSite app pool in IIS.

Also note that whenever you update WAP, this file will get overwritten, so I recommend keeping it in TFS or somewhere similar so that you can re-deploy it after all updates.

@Adam_Dzyacky: I was also hoping to get a line graph going, similar to the graph in WAP and some other views of schedule objects, etc., but I have seen similar issues.  It does seem to be related to the queries, and it seems to be more of an issue when using CTEs (although I have plenty of queries that use them and work...).  What was truly disappointing to me, however, was that the OData widget does not work with the SMA OData endpoint. 

Tom_Hendricks

There seems to be no issue at all with installing WAP on the SMA management server.  Both seem to be light on resource usage, especially when compared to SCSM.

WAP is nice and convenient, but I would hardly call it necessary.  In theory, you could recreate nearly all of its dashboards in the Cireson portal by querying the SMA DB, and you could perform all the WAP functionality with a combination of TFS release integration, the SMA Toolkit in Powershell ISE, and some creative use of catalog forms.  Or any number of other interfaces.  SMA can be controlled via PowerShell and via web service, so it is quite versatile, but BYOI (bring your own interface).

Note that if you are installing WAP, it is possible to disable all the (visible) modules other than "Automation" in the admin portal, if you like.  You also only need to run about 3 of the 13 different sites that WAP installs, if only using it with SMA.  Every update sends you back to out-of-box config on the module visibility and which sites are active, so you'll want to script that or have something to push from TFS/Git/etc. after updates to WAP.

Eric_Krasner

@Tom_Hendricks
Is there any issue in using the Orchestrator SQL server for the WAP DB?

Tom_Hendricks

I have not found any issues with it whatsoever.  Neither is anywhere near as much of a resource hog as service manager or SCOM, so your SQL server can be modest by comparison.

Eric_Krasner

@Tom_Hendricks
You noted above that you could hide items in the left hand panel in WAP. How do you go about doing that? I have been searching for a method but have come up empty.

Adam_Dzyacky

Tom_Hendricks said:

In theory, you could recreate nearly all of its dashboards in the Cireson portal by querying the SMA DB

...I mean it's not as though it's SQL queries against about 3-4 tables for job status, joins for names, joins for putting it all in the same data set, or just grabbing the Stored Procedures directly from the SMA DB then displaying it on the Cireson Portal that supports click filtering just like the WAP and then continuing to leverage the Cireson Portal as the front and center to the entire System Center stack.

Ok but in all seriousness, I actually made this attempt awhile ago when the SQL Widget debuted and was reminded of it once again reading this. Stored Procs were pulled, everything works in SQL/Excel, but can't get one of them to render because the Cireson Portal SQL Widget doesn't seem to like creating tables in memory. That said, I have half of the WAP Automation UI rendering on the Cireson SCSM Portal in that the SQL Table Widget shows the most recent jobs and their respective updates just like the bottom of the WAP Automation page does.

Tom_Hendricks

@Eric_Krasner, here is the file that you would need to edit:
[IIS Site Root]\InetPub\MgmtSvc-AdminSite\Manifests\UiManifest.xml

Look for <extension> nodes, and note the "name" attribute, which will tell you what each is for.  Just comment out (using <!-- and -->) the entire node and its contents for anything that you don't want to see, such as "PlansAdminExtension" or "SqlAdminExtension."  Note that some extensions need to be kept even if you do not think you are using them, such as "AppExtension," "MonitoringExtension," etc.  The one that displays SMA is called "AutomationAdminExtension."

Your changes will not be visible until after you recycle the MgmtSvc-AdminSite app pool in IIS.

Also note that whenever you update WAP, this file will get overwritten, so I recommend keeping it in TFS or somewhere similar so that you can re-deploy it after all updates.

@Adam_Dzyacky: I was also hoping to get a line graph going, similar to the graph in WAP and some other views of schedule objects, etc., but I have seen similar issues.  It does seem to be related to the queries, and it seems to be more of an issue when using CTEs (although I have plenty of queries that use them and work...).  What was truly disappointing to me, however, was that the OData widget does not work with the SMA OData endpoint. 

Leigh_Kilday

Adam_Dzyacky said:

the Cireson Portal SQL Widget doesn't seem to like creating tables in memory.

Have you tried defining your query as a view object in the DB? Views are treated as tables so you may find that it works.

Adam_Dzyacky

When I get a chance, I'll try making this native Microsoft Stored Proc it's own View on the SMA DB. That's an "unsupported" change of an additive nature, but I'd be more than comfortable making it.

Brian_Wiest

@Adam_Dzyacky We accomplish making our own tables and view via another DB within the same instance. This was your addition is not in the SMA DB just pulling data from it. So you don't affect your "supported configuration"