For IT professionals and system administrators leveraging Microsoft System Center Orchestrator (SCORCH), the “Get Lines” activity is a subtle but critical component in automation workflows. At its core, it allows workflows to read and process content from files line-by-line—enabling a host of downstream actions ranging from user provisioning to log analysis. If you’ve searched for a clear, technical yet human-readable example of the “Get Lines” activity in MS Orchestrator, this article is designed to answer that question in both depth and clarity – MS Orchestrator Get Lines Activity Example.
We will begin with fundamentals, proceed through setup, and then move on to advanced use cases with relevant real-world applications.
What is MS Orchestrator and Why “Get Lines” Matters
Microsoft System Center Orchestrator is a workflow automation engine designed to help organizations automate the creation, monitoring, and deployment of IT processes. It acts as a backbone for IT operations, allowing admins to integrate multiple systems like Active Directory, Exchange, ServiceNow, Azure, and even custom scripts.
The “Get Lines” activity, part of the Text File Management IP (Integration Pack), reads one or more lines from a text file. At first glance, this might seem trivial. However, when incorporated into a data pipeline or workflow, it becomes a powerful enabler for – MS Orchestrator Get Lines Activity Example:
- Log parsing
- Data extraction
- Batch user or asset creation
- Scheduled audits
- Event-driven responses
Let’s understand this with an example and then examine its mechanics, configuration parameters, limitations, and creative uses.
Use Case Example: Parsing Server Log Files for Errors
Scenario:
Imagine a systems engineer needs to monitor multiple application servers. These servers log errors to a local .log file. Each night, the engineer wants a SCORCH runbook to automatically:
- Open the log file
- Read all lines
- Filter for lines containing the word “ERROR”
- Create an incident in ServiceNow for each matched line
Here’s how this can be achieved using “Get Lines”.
Setting Up the “Get Lines” Activity
Required Components:
| Component | Purpose |
|---|---|
| Runbook Designer | To create and design workflows |
| Integration Pack: Text File Management | Enables the “Get Lines” activity |
| Target Text File | The source file (e.g., server.log) |
| Filter Criteria (optional) | Conditions for parsing lines |
| Downstream Activities | Steps following the retrieval (e.g., Send Email) |
Step-by-Step Breakdown
- Add the Get Lines Activity:
In the Runbook Designer, drag and drop the “Get Lines” activity from the Text File Management IP. - Configure File Path:
Specify the full path to the log file (e.g.,C:\Logs\server.log). Ensure the SCORCH service account has read permissions on this file. - Set Line Options:
- Start Line: Set to
1to start at the top. - End Line: Leave blank to read till EOF.
- Line Separator: Default is
\r\non Windows. - Return as Published Data: Yes (this will be used downstream).
- Start Line: Set to
- Add Filtering (Optional):
If the use case demands pre-filtering (e.g., only lines with “ERROR”), you can integrate a “Filter” activity after retrieving lines. - Use Published Data:
The output of each line is published individually. You can loop over them or trigger additional actions.
Practical Example: Building the Runbook
Let’s break down the runbook structure with activities:
| Step | Activity | Description |
|---|---|---|
| 1 | Monitor Date/Time | Scheduled trigger (e.g., every 24 hours at midnight) |
| 2 | Get Lines | Reads all lines from C:\Logs\server.log |
| 3 | Filter | Selects only lines containing the string “ERROR” |
| 4 | Format Text | Prepares the message to send |
| 5 | Create Incident (ServiceNow) | Sends line data to ServiceNow via REST API |
This modular approach allows for scalable automation. If tomorrow you want to parse lines for “WARNING” too, a simple addition of another filter path can suffice.
Real-World Challenges & Tips
1. File Locking:
SCORCH may fail if the file is being written to by another process. To avoid this, schedule your runbooks during low server activity times or read from a shadow copy.
2. Encoding Issues:
Ensure files are saved in UTF-8 or ANSI. Non-standard encodings may cause character issues or unreadable outputs.
3. Line Count Limitations:
Though technically not capped, parsing extremely large files (100k+ lines) may cause memory issues. In such cases, use pagination by setting “Start Line” and “End Line” in batches (e.g., 1–5000, then 5001–10000).
Common Configurations for “Get Lines”
| Configuration Option | Description | Recommendation |
|---|---|---|
| Start Line | Line to begin reading from | 1 unless resuming |
| End Line | Line to stop at | Leave blank for all lines |
| Return Line Text | Whether to publish the text of the line | Always “Yes” |
| Line Separator | Character used to detect line endings | Default (\r\n) works for Windows files |
| Output Encoding | Format of returned text | Match source file encoding |
Advanced Use Case: User Provisioning from CSV
Another valuable scenario for “Get Lines” is automated user provisioning. Consider a CSV with new hires:
graphqlCopyEditJohn,Doe,jdoe@company.com,IT
Jane,Smith,jsmith@company.com,Finance
You can use “Get Lines” to:
- Read each line
- Split values by comma (using a “Run .NET Script” activity)
- Create AD accounts via the “Create User” activity
This shifts hours of manual onboarding to a zero-touch model, making “Get Lines” a pivotal part of the automation chain.
Using “Get Lines” with PowerShell
For complex parsing, you may combine it with PowerShell scripts. For example, after “Get Lines”, a PowerShell activity might:
- Strip whitespace
- Match regex patterns
- Serialize data to JSON for API submission
This hybrid approach bridges the gap between simple parsing and rich logic.
Troubleshooting: When “Get Lines” Doesn’t Work
| Problem | Possible Cause | Resolution |
|---|---|---|
| Empty Output | Incorrect file path or access issues | Verify file exists and has read permissions |
| Garbled Characters | Encoding mismatch | Convert file to UTF-8 |
| Partial Line Reads | Non-standard separators | Manually specify correct line separator |
| Sluggish Performance | Huge file size | Use batch line ranges |
| Workflow Stops Midway | Fault in downstream logic | Add logging and isolate the failing step |
Security Considerations
When automating file-based workflows:
- Restrict file access permissions.
- Avoid hardcoding paths—use variables or configuration items.
- Always sanitize input, especially when integrating with APIs or Active Directory.
Monitoring and Auditing
A good practice is to log the outcome of each run:
- Total lines read
- Lines filtered
- Actions taken (e.g., how many tickets created)
This can be appended to a summary log or emailed to admins.
Extending Functionality with Other Integration Packs
“Get Lines” is just one tile in a mosaic. When used with:
- Active Directory IP: Account management
- Scripting IP: Regex processing or tokenization
- REST IP: API-driven ticket creation
- CSV/IP: Structured data import/export
…you unlock wide-ranging capabilities.
Future Outlook and Evolving Practices
As organizations shift towards cloud-native automation (e.g., Azure Logic Apps, Power Automate), traditional SCORCH solutions still play a vital role in hybrid or on-prem infrastructures. Learning how to use foundational activities like “Get Lines” positions IT teams to maintain robust automation while gradually transitioning to modern platforms.
Conclusion: Why “Get Lines” is More Than a Simple Read
In complex IT environments, small tools often play outsized roles. The “Get Lines” activity may appear basic, but when implemented strategically, it becomes a linchpin for automated workflows, reducing errors, saving hours, and enabling rapid response to events – MS Orchestrator Get Lines Activity Example.
Whether parsing logs, provisioning users, or transforming data, mastering “Get Lines” is an essential step in becoming a proficient SCORCH user. Its simplicity is its strength, and its flexibility is its superpower.
In a world where automation is no longer a luxury but a necessity, those who understand and leverage tools like “Get Lines” will lead the way forward.
FAQs
1. What exactly does the “Get Lines” activity do in MS Orchestrator?
The “Get Lines” activity reads one or more lines from a text file, such as logs, CSVs, or configuration files. Each line can be published as output and used in downstream activities for filtering, data transformation, or triggering events.
2. Can the “Get Lines” activity process large files efficiently?
While it can read large files, performance may degrade with extremely large files (e.g., 100,000+ lines). To handle such cases, use batching by specifying Start Line and End Line, or pre-process the file to reduce size before reading.
3. How do I filter for specific content like “ERROR” or “CRITICAL” in log files?
You can filter after “Get Lines” using a “Filter” activity or a “Run .NET Script”. These steps allow you to evaluate each line and pass through only those that match specific strings or patterns using conditions or regex.
4. What file formats are compatible with “Get Lines”?
“Get Lines” works with any plain text file, including .log, .txt, .csv, and .ini. It does not parse binary formats or Excel files natively. Ensure the file uses standard line breaks (\r\n or \n) and a readable encoding like UTF-8.
5. Why am I getting blank output from “Get Lines”?
Common causes include:
- Incorrect file path
- Lack of read permissions
- The file being locked by another process
- Non-standard encoding (like UTF-16 or UTF-32)
Check each of these factors to troubleshoot the issue effectively.