Symantec Connect user Turl posted a forum question asking how to add a computer to an Active Directory group in a Workflow project, because in the Active Directory component library, there’s no boxed component to do this.
I am trying to add a computer to an AD-Group in my Worklfow.
How can that be done?
I know that there is a component to add user to a Group. But there is no component for computers.
Does anyone have an idea how this could be solved?
After a bit of effort (and learning, as I am not presently a respectable coder), I was able to create a custom C# Code (Script) Component that accomplishes this task.
I had the opportunity today to respond to a post on the Symantec Workflow forums, here, regarding writing data to an Excel file. Here’s a quick go-to on how to do it.
Let’s have a look at two different scenarios. The first being that there’s a file that’s being output to a specific location (like a log file), and the second, that a user is downloading report data to an excel file that will be saved to their default download directory.
Both scenarios are illustrated in the demo project for this post, and require the import of the LogicBase.Components.Office.dll library (Microsoft Office).
*Note that this method can also be applied to a number of other scenarios, but an important third scenario would be sending an Excel file via the Send Email component as the file attachment.
All day this past Friday I was trying to get either the Active Directory components or the LDAP generated components to return some usable information on whether an account was locked out. The only results I was able to get back was what I can only guess is some sort of riddle.
So, turns out that the solution for converting that into usable data was going to require way more effort than I was willing to give it, so I figured I may as well use my time for something more useful, like starting to learn C#.
The result of 2 days’ worth of effort finally paid off, and I’m able to pull a readable, usable value for an account’s lockout status. I’m also able to set a password and unlock that account pretty easily. Here’s some info on how to do it.
For every project I develop, there’s a high probability that a custom-made SQL database is going to be useful to the process I’m working on. I’m going to detail my process here, which should be a good follow-up to my SQL primer here.
Note that while this is not intended to be a tutorial on how to use SQL, I will be covering the SQL basics needed to complete this demo. Send me a note if you have any issues with any of the steps.
For this project, we’re going to build an integration library with two components. One component is going to be a simple data query component that we’ll use to validate a proposed data write before committing; the second will be the Stored Procedure caller that will handle updates, inserts, and deletes. The same component can also be used for other, more specific tasks, such as order changes and re-sorting. Let’s start with the second component – the Stored Procedure caller.
I’ve been having a hell of a time with this one for the past few days. I’m developing a project that validates and, if necessary, installs, repairs, or updates any external values needed. This includes SQL data and Application Properties in the ProcessManager portal/DB. The SQL part was no issue, but the profile values were making me really work hard for success.
Set Profile Values is the component I finally got to work.
While Workflow is typically associated with ServiceDesk (as SD is built on the Workflow platform) for ticketing, Workflow can be used to send data to any supported and available web service, and thereby can be used to integrate with other ticketing systems. In this case, I’m going to detail the process for creating ServiceNow tickets with Workflow.
Because I perform nearly all of my Workflow development and labwork locally on my workstation, I do not want to have Exchange and Outlook and all that running in a VM someplace just to handle AD and email testing, nor do I want to maintain some other free, open-source mail server. I found that with a few dummy Gmail accounts and a Send Email Component Via SMTP component, I could do all the notification/email testing I need without the extra computing resource overhead.
SQL integration of some sort has been involved in almost every project I’ve done. Saving and fetching data is just part of it; the SQL engine can be used to quickly do calculations and filtering for your data with the right scripting. If I’m able to fetch and filter the appropriate data from SQL to begin with, I don’t have to then run through a Configurable Collection Filter to get the results I want.
Buried in this process are way too many static values (not to mention that this screenshot will be a great illustration for my “Making Modular Workflows” article I’m working on).
When I first started developing Workflows, especially processes that integrated with other systems (SQL in particular), I would occasionally run into this:
“Hi Andrew, we need to move the SQL server you’ve integrated with. Here’s the new connection info. Hope it’s not a big deal. You declared your connection string variable up front, right?”
Oops. Well, dozens of components buried in layers of embedded models later, I had updated all the SQL components. Except this time, I used a project property. The next time the SQL connection string needed to change, I updated a single value, published, and enjoyed the success.