Python para IT: entorno virtual, un CSV, una API con token, un informe programado y el script que falla en el servidorPython for IT: virtual environment, a CSV, an API with a token, a scheduled report and the script that fails on the server

What you'll get

A Python script that reads a list of devices from a CSV, asks a REST API for each one's status, writes a report as CSV and HTML, leaves a log of what it did and runs by itself every morning. It is the pattern of almost any operations automation: input, query, report, schedule. And what to do when it works on your machine and fails on the server.

Before you start

• Python 3 from python.org (on Windows, with the py launcher) or the system one on Linux.
• A folder for the script, for example C:\scripts\device-report or /opt/device-report.
• The API URL and a read-only token, requested from whoever administers it.
• If the company uses a proxy with TLS inspection, the corporate CA certificate in PEM format (the network or security team will give it to you).

1. One virtual environment per script

Each script with its own libraries, without touching the system Python:

›cd C:\scripts\device-report›py -m venv .venv›.\.venv\Scripts\Activate.ps1›pip install requests›pip freeze > requirements.txt

On Linux, python3 -m venv .venv and source .venv/bin/activate. With requirements.txt the environment is rebuilt on another server (pip install -r requirements.txt); .venv is not copied or put in Git.

2. The script

import csvimport htmlimport loggingimport osfrom datetime import date import requests API = "https://api.contoso.local/v1/devices"TOKEN = os.environ["INVENTORY_TOKEN"]  # never written in the codelogging.basicConfig(filename="report.log", level=logging.INFO, encoding="utf-8",                    format="%(asctime)s %(levelname)s %(message)s") def status(device):    r = requests.get(f"{API}/{device}", headers={"Authorization": f"Bearer {TOKEN}"}, timeout=15)    r.raise_for_status()    return r.json() rows = []with open("devices.csv", newline="", encoding="utf-8-sig") as f:    for line in csv.DictReader(f):        name = line["Device"]        try:            d = status(name)            rows.append({"Device": name, "OS": d.get("os"), "Last seen": d.get("lastSeen")})        except requests.RequestException as e:            logging.warning("%s: %s", name, e)            rows.append({"Device": name, "OS": "", "Last seen": "ERROR"})logging.info("%d devices processed", len(rows)) out = f"report-{date.today()}.csv"with open(out, "w", newline="", encoding="utf-8-sig") as f:    w = csv.DictWriter(f, fieldnames=["Device", "OS", "Last seen"])    w.writeheader()    w.writerows(rows) cells = "".join(f"<tr><td>{html.escape(str(x['Device']))}</td><td>{html.escape(str(x['OS']))}</td>"                f"<td>{html.escape(str(x['Last seen']))}</td></tr>" for x in rows)with open(out.replace(".csv", ".html"), "w", encoding="utf-8") as f:    f.write(f"<meta charset='utf-8'><table><tr><th>Device</th><th>OS</th><th>Last seen</th></tr>{cells}</table>")

What matters in each part:

• encoding="utf-8-sig" when reading: Excel saves CSVs as UTF-8 with a BOM, and without -sig the first column is called \ufeffDevice and the KeyError is baffling. When writing, the BOM makes Excel open accented characters correctly.
• timeout=15: without it, an API that doesn't respond leaves the script hanging forever, and the scheduled task never finishes.
• raise_for_status() turns a 401 or a 500 into an exception the try catches: one failing device doesn't bring down the whole report, and it ends up in the log.

3. The token, in an environment variable

The token is a password. It doesn't go in the script, the CSV or Git. It goes in an environment variable of the user who runs the script:

›[Environment]::SetEnvironmentVariable("INVENTORY_TOKEN", "paste-the-token-here", "User")# open a new console so it picks it up›py -c "import os; print('INVENTORY_TOKEN' in os.environ)"True

On Linux, in a chmod 600 file owned by the service account. With a secrets store (Key Vault, CyberArk), the token is read from there.

4. Scheduling it

On Windows, with Task Scheduler, using the virtual environment's Python and the script folder as the start directory:

›$a = New-ScheduledTaskAction -Execute "C:\scripts\device-report\.venv\Scripts\python.exe" -Argument "report.py" -WorkingDirectory "C:\scripts\device-report"›$t = New-ScheduledTaskTrigger -Daily -At 07:00›Register-ScheduledTask -TaskName "IT\Device report" -Action $a -Trigger $t -User "CONTOSO\svc-reports" -Password (Read-Host "Password")

On Linux, with the service user's crontab -e:

0 7 * * 1-5 cd /opt/device-report && . ./token.env && .venv/bin/python report.py

Without -WorkingDirectory (or the cd in cron), the script looks for devices.csv in C:\Windows\System32 or the home folder, and fails with FileNotFoundError even though it worked by hand.

5. The ticket: "it works by hand, it fails when scheduled"

The task's log says one of these three things:

1. KeyError: 'INVENTORY_TOKEN': the task runs under another account (svc-reports) and the variable was defined for your user. Define it for the service account, or at machine level if policy allows.
2. UnicodeDecodeError: 'utf-8' codec can't decode byte 0xf1: someone saved the CSV as CSV (Comma delimited) instead of CSV UTF-8, and it comes in cp1252. The proper fix is to ask for the file in UTF-8; in the meantime, encoding="cp1252" for that specific source. If the error is UnicodeEncodeError when printing, it is the Windows console: the PYTHONUTF8=1 variable on the task avoids it.
3. ProxyError or SSLError: CERTIFICATE_VERIFY_FAILED: in your session the proxy comes from the user's settings and in the task it doesn't. requests uses the HTTPS_PROXY and NO_PROXY variables; and if the proxy inspects TLS, it needs the corporate CA in REQUESTS_CA_BUNDLE.

›[Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.contoso.local:8080", "Machine")›[Environment]::SetEnvironmentVariable("NO_PROXY", "localhost,.contoso.local", "Machine")›[Environment]::SetEnvironmentVariable("REQUESTS_CA_BUNDLE", "C:\scripts\ca\contoso-root.pem", "Machine")

verify=False makes the error go away and leaves the connection open to anyone who sits in the middle, with the token travelling inside it. It is not used, not even "to test".

Next steps

• The PowerShell guide covers the same in Windows' native language; many IT tasks are better done in one or the other, and it pays to know both.
• Microsoft Graph: the same script structure works for reading Intune devices or Entra ID users, with an application token instead of a fixed one.
• Once you have several of these scripts, the next step is a console that brings them together. That is the idea behind the 05-it-ops-console repository on my GitHub.

Is something missing, or different in your environment? Get in touch and I'll fix it.