39f2f75d7b50747c28bf3737b3b64af96f95fd3b
1 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
| ba2ed379f8 |
feat: Add AD2 WinRM automation and modernize sync infrastructure
Comprehensive infrastructure improvements for AD2 (Domain Controller) remote management and NAS sync system modernization. ## AD2 Remote Access Enhancements **WinRM Configuration:** - Enabled PowerShell Remoting (port 5985) with full logging - Configured TrustedHosts for LAN/VPN access (172.16.*, 192.168.*, 10.*) - Created read-only service account (ClaudeTools-ReadOnly) for safe automation - Set up transcript logging for all remote sessions - Deployed 6 automation scripts to C:\ClaudeTools\Scripts\ (AD user/computer reports, GPO status, replication health, log rotation) **SSH Access:** - Installed OpenSSH Server (v10.0p2) - Generated ED25519 key for passwordless authentication - Configured SSH key authentication for sysadmin account **Benefits:** - Efficient remote operations via persistent WinRM sessions (vs individual SSH commands) - Secure read-only access for queries (no admin rights needed) - Comprehensive audit trail of all remote operations ## Sync System Modernization (AD2 <-> NAS) **Replaced PuTTY with OpenSSH:** - Migrated from pscp.exe/plink.exe to native OpenSSH scp/ssh tools - Added verbose logging (-v flag) for detailed error diagnostics - Implemented auto host-key acceptance (StrictHostKeyChecking=accept-new) - Enhanced error logging to capture actual SCP failure reasons **Problem Solved:** - Original sync errors (738 failures) had no root cause details - PuTTY's batch mode silently failed without error messages - New OpenSSH implementation logs full error output to sync-from-nas.log **Scripts Created:** - setup-openssh-sync.ps1: SSH key generation and NAS configuration - check-openssh-client.ps1: Verify OpenSSH availability - restore-and-fix-sync.ps1: Update Sync-FromNAS.ps1 to use OpenSSH - investigate-sync-errors.ps1: Analyze sync failures with context - test-winrm.ps1: WinRM connection testing (admin + service accounts) - demo-ad2-automation.ps1: WinRM automation examples (AD stats, sync status) ## DOS Batch File Line Ending Fixes **Problem:** All DOS batch files had Unix (LF) line endings instead of DOS (CRLF), causing parsing errors on DOS 6.22 machines. **Fixed:** - Local: 13 batch files converted to CRLF - Remote (AD2): 492 batch files scanned, 10 converted to CRLF - Affected files: DEPLOY.BAT, NWTOC.BAT, CTONW.BAT, UPDATE.BAT, STAGE.BAT, CHECKUPD.BAT, REBOOT.BAT, and station-specific batch files **Scripts Created:** - check-dos-line-endings.ps1: Scan and detect LF vs CRLF - convert-to-dos.ps1: Bulk conversion to DOS format - fix-ad2-dos-files.ps1: Remote conversion via WinRM ## Credentials & Documentation Updates **credentials.md additions:** - Peaceful Spirit VPN configuration (L2TP/IPSec) - AD2 WinRM/SSH access details (both admin and service accounts) - SSH keys and known_hosts configuration - Complete WinRM connection examples **Files Modified:** - credentials.md: +91 lines (VPN, AD2 automation access) - CTONW.BAT, NWTOC.BAT, REBOOT.BAT, STAGE.BAT: Line ending fixes - Infrastructure configs: vpn-connect.bat, vpn-disconnect.bat (CRLF) ## Test Results **WinRM Automation (demo-ad2-automation.ps1):** - Retrieved 178 AD users (156 enabled, 22 disabled, 40 active) - Retrieved 67 AD computers (67 Windows, 6 servers, 53 active) - Checked Dataforth sync status (2,249 files pushed, 738 errors logged) - All operations completed in single remote session (efficient!) **Sync System:** - OpenSSH tools confirmed available on AD2 - Backup created: Sync-FromNAS.ps1.backup-20260119-140918 - Script updated with error logging and verbose output - Next sync run will reveal actual error causes ## Technical Decisions 1. **WinRM over SSH:** More efficient for PowerShell operations, better error handling, native Windows integration 2. **Service Account:** Follows least-privilege principle, safer for automated queries, easier audit trail 3. **OpenSSH over PuTTY:** Modern, maintained, native Windows tool, better error reporting, supports key authentication without external tools 4. **Verbose Logging:** Critical for debugging 738 sync errors - now we'll see actual SCP failure reasons (permissions, paths, network issues) ## Next Steps 1. Monitor next sync run (every 15 minutes) for detailed error messages 2. Analyze SCP error output to identify root cause of 738 failures 3. Implement SSH key authentication for NAS (passwordless) 4. Consider SFTP batch mode for more reliable transfers Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com> |
