Skip navigation

Server Automation

14 Posts authored by: Sean Berry Moderator
Share:|

[now with updated compliance policy template]

 

So, CVE-2017-0144 https://nvd.nist.gov/vuln/detail/CVE-2017-0144, a vulnerability that was identified about two months ago (published Mar 16 2017), is now being widely exploited in the wild, most visibly impacting hospitals in the UK’s National Health Service to the point that they’ve had to redirect incoming patients to other facilities.

This vulnerability is addressed by Microsoft Bulletin MS17-010, which is also included in OS-specific Security Bulletin (roll-ups) SB17-002, SB17-003, SB17-004.  MS17-010 applies to Server 2003 and Server 2008, while SB17-002 applies to Server 2008 R2, SB17-003 applies to Server 2012 R2 and SB17-004 applies to Server 2012 (thanks to Joe Schuler)

 

Part of what makes the vulnerability so serious is that it doesn’t require direct action by the user, simply having the vulnerability and being on the same network as an infected host can expose your system to the ransomware.

 

Wana Decrypt0r screenshot.png

(source: Wikipedia)

 

 

The good news is that the required hotfix is easily identified and applied using either BMC Server Automation or SecOps Response Service.  We’ve shown three routes you can use to apply this fix: Patching Job, a Compliance Job, and Vulnerability Remediation (SecOps Response).

We'll shortly post a video for the Patching approach.

 

For the patching approach, first start by updating your Windows Patch Catalog if it hasn’t updated since at least May 13.  Microsoft has released updates for now-unsupported operating systems including Windows XP and Server 2003, that are included in this update.  To do this, right-click on your Windows Patch Catalog, and select “Update Catalog”

 

 

This task may take a few minutes to complete.

While that is running, you can create a Patch Smartgroup that identifies any “Windows Bulletin” where name equals “MS17-010”.  You may also want to include the OS-specific security bulletins SB17-002, SB17-003, SB17-004, which include MS17-010.

And once your catalog update completes, you can run a Patch Analysis (Patching Job) to identify which servers need this patch.  To do that, right-click on the new Patch Smart Group, and select “Analyze Patch(s)”:

 

This will create a Patching Job that focuses on this particular bulletin.

 

Note that we are analyzing in List mode, using the MS17-010 Patch Smartgroup we just created.  Click Next.

 

 

If you want to create remediation artifacts (packages and jobs to deploy the patches), click the checkbox at top.

 

 

You may need to select appropriate places to save the Packages and Batch/Deploy Jobs if you have not used this feature before, otherwise they will default to the same values used previously.  To have the remediation jobs execute either immediately or on a schedule for a later time, click on Deploy Job Options…”,

 

 

And select either “Execute job now” or select a time for “Execute selected phases” as appropriate.  Here I’ve set this up to start executing at 10PM, or “22:00”.

Click ok, and on the next screen, select the appropriate Server Smartgroup to audit, and click Next.

 

 

On the Notification page, I like to send notifications to either the client that owns these systems, or to myself, so I’ve put in my own email address, selected all three conditions: Success, Failed, Aborted, append results to email, and asked it to keep it under 1MB.  Click next.

Because I want these results right away, I click “Execute Job Now”, and click Finish:

 

 

I will shortly have patching results indicating where I have already applied, and where I still need to apply MS17-010.

Here I see that I have 4 servers that need this patch.

 

 

Since I selected to create the remediation objects, and to schedule them, they will run tonight at 10PM.

Once they've executed, we can look at the deploy status of these patches:

In this example, two servers did successfully remediate, but still need a reboot (this is another option in the job options, to reboot after deployment).  Some teams will avoid scheduling the reboot to allow them to deploy patches as fast as possible, then reboot when the maintenance window becomes available.

In this case, I'm going to sort by the servers that need the manual reboot, and reboot them directly from BSA by right-clicking on the green checkmarks, and selecting "reboot".  (There's also an NSH Script that will reboot servers at scale, and you can always right-click, advanced, Reboot").

Now they'll reboot, and come back up fully patched shortly:

 

To audit this using Compliance, simply build a rule that looks for whether MS17-010 is installed (This policy is attached as a version-neutral export).  Unfortunately, since there's no registry key to inspect for this bulletin, we can't use registry-keys to check.

Let's see how easy this is in SecOps Response first let's login to our tenant using BSA:

I imported my latest scan info, then went over to the Operator Dashboard.  Filter by "CVE-2017-0144", and it shows me exactly which systems have this vulnerability detected on, and that the oldest detection is 22 days old (and now in violation of SLA, being a critical vulnerability):

 

I scroll down and see all the systems that I can remediate.

Click remediate:

 

 

I'm going to deselect one server, but continue with the rest:

Select "Execute Now":

Select some notifications, then hit execute now.

 

Isn't that easy?

Sean Berry

Engage Call For Papers

Posted by Sean Berry Moderator Mar 1, 2015
Share:|

Not sure how we didn't get this posted here, but while the deadline was an hour ago, if you want to submit something between now and Monday, I think it'd be worth doing.  BMC Engage 2015 - Call for Papers window now open

 

I gather that with an accepted paper they might waive the registration fee.  I put in 17 proposals, you've each got to have at least one good idea you could talk about for an hour.  Last year Carfax, State of Michigan, BMO, and half a dozen others presented on neat things they'd done with Automation.

Share:|

Ok, so this is was going to be a quick post...

 

I go to see customers as often as I possibly can, and one thing I get asked a lot is: how can I get my ticket addressed quickly?  We've all felt the frustration of opening a ticket (with any vendor) and feeling like we get asked either the same questions over and over, or that we get asked for basic information that should be obvious.  I have a couple of things I use to solve these problems.  [tl;dr: a well-documented ticket get solved faster]

 

When I started at BladeLogic at the dawn of time (ca. late 2004), I was very fortunate to be in the first(?) generation of Professional Services people hired after @jboland.  While there was organized training in early 2005, most of us were trained by Support, usually when we opened a poorly qualified ticket.  Usually John O'Toole, Newton Nyante or one of his peers would take a minute and explain to me why "Job doesn't work" wasn't the best subject line for a ticket.  One of the things I learned early was that if you wanted your ticket addressed quickly, you had to put what you wanted up front, what you'd already tried, and include the most relevant logs or errors.

 

 

So I made up a cheat sheet slide for "How to Succeed at BladeLogic Without Really Trying". (see footnote 2)

 

It basically boils down to four parts:

 

  1. What was I trying to do?
  2. What did I expect to happen?
  3. What happened instead?
  4. What do I want you to do about it?

 

There's some not-necessarily-obvious parts to this. 

 

  1. The better you can explain not just what button you were clicking on, but what problem you were trying to solve, the more likely it is that the person on the other end of the phone/email/ticket will understand what's going on. 
  2. If you're expecting something that doesn't quite work that way, or if there's a better/faster/easier way to accomplish what you're trying, this opens the door for them to help you get to the best way to do it.  The more clearly you can communicate how you think it should work, the easier it is for the support person to understand and clarify.
  3. Sometimes what happened... is what's supposed to happen.  "Works as designed" may be the most frustrating ticket response in the world, but it opens the door to "so, how would we do this?".
  4. Support (and Product Management, Development, and Customer Engineering behind them) can do a number of different things with any given issue, from simply:
    1. logging it for consideration for a future release or service pack or helping you open an Idea,
    2. identifying it as fixed in a current shipping release,
    3. suggesting a workaround, to
    4. escalating it and helping obtain a hotfix. 

 

In the short term, depending on what kind of fix is needed, a workaround may be the most expedient way to get you working.  It's rarely the most satisfying, but is usually the most productive, if there is a way.  In the event that a hotfix is needed, the more clearly we can define how we want it to work, or what needs to be changed, the better.  Smaller fixes or behavior changes generally require less development time, less QA, and will result in getting a fix that much faster.  If the request is too big, it may end up having to go into a future release.

 

This is also the opportunity to identify the severity and priority of the issue: what's the business impact of feature X not working as expected?

 

Last thing: if you have a relevant, specific log snippet or screenshot, please include it (and ideally the timestamp and larger log file if practical).  There are a bunch of well-identified issues logged with their relevant error message in the KB, and even if what you're seeing doesn't match there, by calling out which log (agent, appserver, gui, job, etc?) you're looking at, it'll help the support person verify the issue.

 

One unintended side effect of putting in tickets this way: I'd say 60% of the time, as I'm putting together my "4 points", I figure out the problem myself, or find the answer in the KB.

 

If you can hit all 4 of the "what to include", the likelihood of your ticket closing quickly and in a satisfactory way improve significantly.  Without you having to work that much harder.

 

Footnotes:

  1. How To Ask Questions The Smart Way. : sysadmin
  2. How To Succeed In Business Without Really Trying (2011 Broadway Revival) - Previ - YouTube
Sean Berry

As you might have heard...

Posted by Sean Berry Moderator Dec 12, 2014
Share:|

BSA 8.6 is out.  Neil Karani covers in some depth all of the new and improved stuff that went into the release here: Announcing BladeLogic Server Automation 8.6.00!!!!, and Ton Machielsen covers how much easier it is to get going in Welcome BSA 8.6!! Welcome to Automation Roll-Out for Dummies.  The Quick Start Page makes it easier than ever to put BSA to work immediately, with "easy buttons" throughout.

 

For those of you who don't yet have a test lab to start putting 8.6 through the paces, 8.5.1 patch 3 is also out: Announcing BSA 8.5 SP1 Patch3.  If you're still on a release older than 8.3.3, 8.5.1, it's time to catch up on Service Packs, and start looking at 8.5/8.6.  Plus, you're going to need to be on 8.5.1 to take advantage of the Automation Portal (1.2 as of today), which is the single easiest way to give web access to BladeLogic to your casual users.

 

We'll likely be revamping some of the Best Practices material in the coming weeks, including a Patching BP manual (yes, I've been talking about it for years, but I've got a quiet week with little travel in it, so I'm going to turn the OOO on and get a first draft in your hands).  We might also convert what's in the BP Webinar videos to a short manual if there's any interest.  If you'd like something like this, tell us about your needs in a comment below, and we'll include it in the plans.

 

By the by, the single easiest way to get BSA 8.6 into your lab is with the Rapid Deployment Stack, a VM that comes with BSA pre-built out on it.  You might need to fiddle with the hardware version (as discussed here: BSA 8.6 RDS not compatible with VMware 5.0), but it's so simple, you could do it while drinking your morning cuppa.

 

Don't miss all the nice New "Automation Academy" videos/articles!  I consider them a more organized and polished version of the original Howto videos Greg K and I made.

 

And, of course, if you don't want to, or can't do any of these, the BladeLogic Dashboard 1.2.00 (Service Health and Value) [Deprecated, use 1.4.00] dashboards can help you get a better grip on what's going on in your existing BSA 8.2-8.5 environment.  They are, of course, built into BSA 8.6.

 

Thanks go out to Neil Karani and the entire Dev, QA, IDD, PM, TM, Marketing etc. team that made this happen, and of course my peers in Support and CE that help keep it all going.

Share:|

Ever wonder how to get servers into BladeLogic?  Many of us are experienced users, but I meet people every week or two that want to know where to start.  What better place than asking how to get a server into BladeLogic so you can manage it?

 

Walkthrough: Adding a Windows managed server - BMC Server Automation 8.5 - BMC Documentation

 

Next step: Live Browse: https://docs.bmc.com/docs/display/bsa85/Walkthrough%3A+Inventory+using+Live+Browse

 

After that: audit a single configuration (like DNS entry, installed app, or service): https://docs.bmc.com/docs/display/public/bsa85/Walkthrough%3A+Audit+a+single+configuration+item

 

Check the overview here: Automation Academy content available for BSA 8.5, and https://docs.bmc.com/docs/display/bsa86/Getting+started, stand by for the official announcement, and I'll link the content from the How do I get started with BladeLogic (BSA)?  How do I learn more about BladeLogic?  How do I use it to do my job?  Solve problems for my company? (Getting Started) page.

 

Many thanks to our great IDD/docs team, to those who've worked on and led this project.

Share:|

If I and a few others wanted to do a Reporting Workshop for a couple of hours on a webex, perhaps starting with an overview of BDSSA, quick tips on ETL & troubleshooting, building some common custom reports in Query Studio and one or two in Reports Studio, then going into some open Q&A time, who would be interested in participating?  I've been building a number of custom reports at customers (inventory, compliance, patching, real-time), and would like to share my experiences and hear yours.

 

Comment here, and let me know of any specific reports you want to build, or business questions you could use help answering or addressing.

 

Some light background reading material on the topic:

 

BSA Reporting Best Practices Webinar - 16 July, 2013

Troubleshooting BDSSA ETL failures in Metadata Navigator

Share:|

1. It now uses a cleaner login screen, in larger type than the old front page.

2. It now includes a security image that gives you a good idea of whether you're looking at the right site.

3. It plugs you into the newer, faster, better docs.bmc.com, with the same great documentation, but now delivered more reliably and faster. 

 

I'm positive on the new platform, but let us know how it looks for you in the comments below.

 

(yes, I did just use cheesy SEO to make you look at this article).

Share:|

  Here's a couple of things you must have, to have a successful implementation of BladeLogic.

 

  1. Basic capacity & performance in infrastructure.  This includes things as simple as having enough memory for the app servers, correctly configuring the relevant amount of memory for an app server per the amount of memory in the app server’s OS.
  2. At least one motivated, capable BladeLogic user to maintain use cases and drive adoption.  Historically this has been the original team that bought BladeLogic.  These individuals are usually enabled on several use cases and “BladeLogic Culture” by the POC or initial implementation, from existing motivated, capable BSA experts. 
  3. At least one important use case, tied to a key, or at least relevant business initiative.
  4. Buy-in, or at least cheerful cooperation from OS platform owners & L2 users, who can make or break agent coverage and ongoing health.
  5. Support & cooperation from the database team, on whose service BSA depends.
  6. Use Case Subject Matter Experts, whose skills, especially design & ongoing support/troubleshooting will ultimately decide whether a use case is sufficiently functional & valuable to keep doing.
Sean Berry

BSA Question of the Day

Posted by Sean Berry Moderator Nov 5, 2013
Share:|

Here's a quick question that came up in discussion today:

 

Question: For an isolated environment, could you setup standalone NSH and RSCD agents, without a App Server?

 

Answer: Certainly: access control is then managed through the users and users.local files.  Some organizations may want to use a NSH Proxy here to provide different kinds of authentication, but this is an easy way to use NSH in a standalone environment.

Sean Berry

Staffing for Automation

Posted by Sean Berry Moderator Sep 10, 2013
Share:|

The basic idea is that in most customers you have platform owners and Subject Matter Experts, and end users.

 

The platform owners, like in any utility, keep the lights on, and troubleshoot basic infrastructure & performance.  In most customers, these are the primary members of the BLAdmins or equivalent role, have local administrative access (root/Administrator) to the Application servers and other infrastructure, and are ideally expert-level systems administrators and automation engineers in their own right.  They directly support the Subject Matter Experts when they run into trouble using the tool.  Any subject-specific product questions they can't answer will likely end up in a support ticket.  They relatively rarely have deep knowledge of all use cases, but usually should be able to answer mid-level questions of how to use BSA to accomplish a given task, and should be able to explain the basic idea of how BSA can help address (and what it doesn't address) around a given use case.  Most customers have at least two people in this role who back each other up.  When there's only one person in this role, it's relatively easy for them to get burnt out.  Also, it's a good practice to have expertise in both UNIX and Windows between the two or more members of the team.   In environments with more than 25,000 servers under management, platform ownership should probably be the responsibility of more than two people: not necessarily due to workload (which doesn't appear to scale linearly), but more as a hedge against turnover and knowledge loss.

 

At the 25,000+ server level RBAC Admin is usually at least a half-time job for someone.  Much less than this, and the RBAC design and implementation tends to lag the business by several years, which leads to challenges, as we've seen.  At the 50,000+ server level, RBAC could be a full-time job for someone.

 

The platform owners are usually backed up by one or more people who maintain agents.  At some customers this is either the responsibility of the entire L2 operations team, key members of that team (as they tend to have the credentials to access servers out-of-band via ssh, RDP, Vmware, lights-out or physical consoles, and can pull in their team members as necessary.)  In some cases this role is played by platform owners (the "Linux Team"), or the team that owns and maintains a given set of servers, often aligned with OS platform, project, or line of business.  In all cases, there needs to be an effective and simple process to deploy, onboard, maintain, and troubleshoot agents.  Ideally this is backed by some sort of agent compliance or health checking, but this is not common in most customers.  This is one staffing area that basically scales linearly with the number of deployed agents: I suspect that it's not uncommon to have 1 person tasked but not dedicated per 2000-5000 agents.  With a 14-20% annual server replacement (reflecting a 5-7 year server lifecycle), and 1-3% of servers down at any given time for maintenance of one sort or another, it's not unlikely that at this staffing level each admin may be asked to look at 20-150 agents per week to diagnose why they're "not visible in BSA".   At scales approaching 25,000 servers, this should be fairly automated, with an agent monitor as standard deployment, and some correlation to OS availability.   It's not uncommon to see BAO workflows doing the first pass of this work in larger environments.  With small (< 5,000 servers) environments, agent health is more commonly done as an ad-hoc activity.

 

The Subject Matter Experts have a fair amount of power within their subject area, and at least enough RBAC access to do their job comfortably.  Without enough access here, the Experts will become frustrated, and decrease their use of the tool in favor of anything that will give them freedom to get the job done with minimum friction, even if it may be a substantially lower-quality or feature competitor (think Puppet or ssh-keys).  For infrastructure-heavy use cases like Provisioning and Patching, they may have a fair amount of access to the core platform, potentially including provisional membership in BLAdmins or an equivalent role.  There tends to be at least one or two SMEs per use case, and one per use case and platform for Patching and Provisioning.  In environments with 25,000 servers or more, there tends to be at least a dedicated SME for Reporting, one for each Patching platform, one for each Provisioning platform, and at least a couple for Compliance (usually aligned UNIX/Windows).  They will usually also be the person to carry the responsibility for executing the business's needs in their given subject area.  This ensures that those doing the work are working from the latest requirements.  As to support, the SMEs may open their own tickets on subject-area issues, but often work with the Platform Owners for infrastructure issues.  For business critical use cases or large environments (25,000+), there are usually several SMEs in a given subject area, sometimes aligned with content creation vs. use case execution or operations.  Report execution and quality control tends to be at least a part time job in any environment with a critical use case (like Compliance for highly regulated industries).

In organizations where there are separate Build and Run or Engineering and Operations groups, the Subject Matter Expert may be in the Build/Engineering role, or there may be another Operational owner for executing the use case.  This is especially common around Patching and Provisioning use cases.  In the case of Patching, since it often is executed  for narrow windows of time as a large scale activity (2-3 days per month on Windows, less frequently for UNIX), the Operational owner will often supervise a small group of end users that execute Patching and audit/QC the results.  Typical ratios here are somewhere between 125 servers per 1 patch administrator at the low end to over 5,000 servers per 1 patch administrator for well-organized enterprises.  The total number of Subject Matter Experts can be as low as 2-3 for small customers, or as many as 25 or more SMEs for large environments with several use cases in play.

 

The end users who are focused on a single use case should ideally work primarily with their Subject Matter Experts for guidance and initial troubleshooting, since they have the highest shared context around how the organization is working a given problem or use case.  In > 10,000 server environments, as they are unlikely to be platform experts or have access to the core platform, basic platform troubleshooting usually goes through the SMEs or through the local product expert.  There may be hundreds or thousands of end users, so it's important to have a scaled level of support staff sufficient to answer questions and address their requests.  Otherwise, the platform owner team will quickly become overwhelmed and frustrated, and quality of service will degrade.

Sean Berry

On Competence

Posted by Sean Berry Moderator Aug 11, 2013
Share:|

With apologies to Robert Heinlein...

 

A sysadmin should be able to: build a new server, import servers, decommission a server, change passwords, audit for compliance, log exceptions, change policies, remediate discrepancies, apply patches, reboot servers, package software, deploy a package, document software coverage, identify the inappropriate, find a bad actor, remediate unauthorized change, speak to value, report on key performance indicators, explain his/her worth, read documentation, document his/her work, adopt new technology, understand history, and work at breathtaking scale.

Share:|

So, one of the more common "service provider", "disaster recovery" or "acquiring company / acquired company" use cases is when you need to access two networks of servers that have at least some overlapping IP addresses.  Either you have two customers that both want to use 10.0.0.0, your DR environment has the same IP addresses as your production environment, or a company that your company bought / that bought your company are all trying to use the same set of IP addresses.  Implied of course is that somewhere in here, there's a firewall that connects these two worlds, and ports in that firewall are relatively expensive, either in initial setup, or just in maintenance.

 

So you have the firewall admin open up one port between these environments, and you setup a SOCKS proxy to route the connections from one side to the other through. 

 

This is a very quick and dirty demo that shows how that's configured.

Share:|

 

I'm sorry, I can't avoid a good Steven Seagal tagline.

 

Last month we ran the first BMC BladeLogic Server Automation Best Practices Webinar (Episode I: Deployment Architecture, (Avoiding Surprises), had > 100 customer participants attend, and had a very active Q&A session at the end. 

 

Next one’s planned for next Tuesday, December 4, at 10AM Central, 11AM Eastern, 8AM Pacific.  We’ll be covering Maintenance, including the ever-dreaded Database Cleanup with up-to-the-minute tips on how to keep your system running fast and efficiently.  I'm furiously assembling the deck from some great source material right this second, and am looking forward to some good questions from you next Tuesday.

 

To register, email Mike Faiella (Michael_Faiella AT  bmc.com). 

 

Previous session recording: https://communities.bmc.com/communities/docs/DOC-21693

BSA BP Webinar Series: https://communities.bmc.com/communities/docs/DOC-21692

Share:|

I talk with customers every week, and there are a number of common topics that come up.  The howto video subjects can come from those conversations, or from specific requests.  This week, I had a couple of different users ask how to get started with software packaging, and it occurred to me that it'd be useful to talk about the basics: where to start.  This video (script attached below) is the first video along those lines.  I cover a bit about common practices I use, and a couple of bits about where basic software packaging is regularly used (hint: full stack provisioning, and Cloud.)

 

Take a look at the video (attached and also on youtube), and let me know your thoughts and questions.

 

 

 

------------------------------------------------------------------------

 

 

Hi, my name is Sean Berry, and I work on the Customer Engineering Operations team, specializing in Data Center Automation and Cloud Lifecycle Management.

 

So, you've got a working BSA instance, agents deployed, etc. and now it's time to deploy some software.  Software packaging and deployment is a common task within automation, and a good opportunity for potentially serious time savings, especially on more complex packages.  It can also rapidly increase the rate at which new servers can be built.  Most organizations have automated the building of a basic server, but the follow-on deployment of the different monitoring, backup, and security agents, server hardening, patching, and compliance validation steps can still take days or longer.  In other organizations, it can be the work of weeks or longer to roll out or upgrade a particularly thorny software package.  The obvious place to start is with basic software deployments.

 

For today's purposes, we're going to work with a simple example package, a compression utility called 7zip.  Any MSI that has a working silent install will work here, and most MSIs fit this requirement. 

 

First we'll need a server to deploy this to: you've probably got many servers available, but in this "lab" environment, I need to add a machine.  I've already defined its hostname and IP address in the system "hosts" file, while you're probably using DNS in one form or another.  I'm now going to add "win08-www" as a server, I'll click on ok, and it'll appear in the server smartgroup when I refresh it.  I like to double click on a server when I first add it, and browse a couple of object types to make sure everything is happy.  Here's the applications list.

 

Ok, now we need software.  I've taken the liberty of downloading this one, and stashing the executable in the c:\temp folder.  Now all I need to do is browse to the depot, go into the workspace folder, right-click, and select new software object -> MSI, and browse to the c:\temp folder on the local machine (as opposed to on another server or a central file server: that'll come later).  Once I select the object, I have the opportunity to customize the installation instructions, add any additional options I might need.  Since this is a very simple software install, I'm going to leave all of this alone and hit OK.

 

Ok, now that I have my object, I need to deploy it: refresh on the depot folder if necessary, right-click, and select "deploy".  This creates a Deploy Job. Between how the object itself is defined, and any customizations made to the job itself, they define together how to get software from the depot to a server.  The Deploy Job is used as a part of a Post Provisioning Batch Job, and by CLM to build a server a certain way.

 

Every job needs a name, and a place to live: while developing new packages and jobs, I will commonly keep these in a Workspace folder.  Once I'm comfortable that they are useful enough to share with others, I'll promote them into shared spaces, like a shared "Software Deployment" folder.

 

I usually skip the "Simulate" stage when I'm developing a new software package, it saves a bit of time, and I'm usually confident that the new server is up and has available space.  I will usually select "Execute Job Now".  I will also usually increase the logging level from "Errors and Warnings" to "All Information", but only for testing and while I'm making sure it will deploy cleanly.  Once it's ready to go to production, I'll change the logging level back, since the "All Information" level generates a lot of information. 

 

Once I click ok, the job will start executing.  While keeping an eye on the "Tasks in Progress", I'll either login to the machine directly, or look at the "Applications" object, which has the same things as the "Add/Remove Programs" Control Panel.  Once I see the application appear in either place, or a directory I expect it to create appear, I'll check back with the job results, make sure it deployed cleanly, test the app a bit, then hand it off and start working on the next app.  Congratulations: you've packaged a simple app, and can now work on either upgrading an older agent in your environment, or combining it with other apps and configurations to build out a full provisioning stack.

 

Many apps require no more work than this to automate, but we'll look at a couple of more complex use cases another time.  Thanks for your time, and thanks for using BMC software.

Filter Blog

By date:
By tag: