About the publication
About Jack Hadcroft and AdminSignal
I am Jack Hadcroft, the author of AdminSignal. I have worked in NHS IT since 2013 and am a Band 6 Endpoint Specialist. My hands-on experience includes MECM/SCCM, Intune co-management, PowerShell, Windows deployment and large Windows estates in an NHS enterprise environment. These are the areas of administration behind the publication’s focus on endpoint management and deployment decisions.
AdminSignal is an independent publication. The articles below connect that subject area to practical questions: how to plan co-management, investigate a failed deployment and validate a change. My professional background is context for the writing, not evidence that every example has been run in a workplace. Each article should distinguish documentation review, illustrative examples and any supported testing claim. Workplace systems and identifying details are not published here. The site does not speak for the NHS or imply employer endorsement. For the verification standard and correction process, see the editorial policy.
Who the site is for
AdminSignal is for people who already own a Microsoft estate and need to change it without guessing. Coverage is organised around tasks administrators actually complete: planning a rollout, identifying prerequisites, limiting blast radius, collecting logs, validating outcomes, and recovering when a change fails.
- Intune and endpoint engineers planning a change, not just reading a feature list
- Windows administrators who need prerequisites, logs, and rollback criteria
- Identity and messaging admins dealing with Conditional Access, MFA, or SMTP AUTH cutovers
- Helpdesk leads who need a diagnosis order they can hand to a technician
What AdminSignal will not publish
- Microsoft Learn rewrites that add no operational interpretation, validation, or risk callouts
- Invented deployments, fake screenshots, unverified certifications, or inflated job titles
- Numerical product ratings or “best tool” lists without documented evaluation evidence
- Complete script downloads presented as tested or production-ready when only fragments exist
- Hub pages that advertise tutorials, products, or coverage the site does not actually have
- Automatic site-wide freshness dates used as a substitute for an article-level review
How articles are produced
- 1Start with a defined administrative task, failure state, rollout decision, or reporting need.
- 2Check product behaviour, portal paths, permissions, and support boundaries against current primary documentation where available.
- 3State prerequisites, assumptions, example values, validation evidence, and rollback considerations when they affect safety or correctness.
- 4Separate documented product facts from AdminSignal interpretation, recommendations, and example workflows.
- 5Correct material errors and record meaningful updates on the affected article rather than advancing a generic site-wide date.
Representative reading
These are the pages a reviewer should open first. Each one starts from an admin decision or failure state, cites current Microsoft documentation, and stays inside published evidence.