Files
claudetools/SYNC_SCRIPT_UPDATE_SUMMARY.md
Mike Swanson 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>
2026-01-19 14:28:24 -07:00

4.9 KiB

Sync Script Update Summary

Date: 2026-01-19 File Modified: \192.168.0.6\C$\Shares\test\scripts\Sync-FromNAS.ps1 Change: Added DEPLOY.BAT to root-level sync


Change Made

Added DEPLOY.BAT sync to match existing UPDATE.BAT sync pattern.

Code Added (Lines 304-325)

# Sync DEPLOY.BAT (root level utility)
Write-Log "Syncing DEPLOY.BAT..."
$deployBatLocal = "$AD2_TEST_PATH\DEPLOY.BAT"
if (Test-Path $deployBatLocal) {
    $deployBatRemote = "$NAS_DATA_PATH/DEPLOY.BAT"

    if ($DryRun) {
        Write-Log "  [DRY RUN] Would push: DEPLOY.BAT -> $deployBatRemote"
        $pushedFiles++
    } else {
        $success = Copy-ToNAS -LocalPath $deployBatLocal -RemotePath $deployBatRemote
        if ($success) {
            Write-Log "  Pushed: DEPLOY.BAT"
            $pushedFiles++
        } else {
            Write-Log "  ERROR: Failed to push DEPLOY.BAT"
            $errorCount++
        }
    }
} else {
    Write-Log "  WARNING: DEPLOY.BAT not found at $deployBatLocal"
}

File Locations

AD2 (Source)

  • C:\Shares\test\UPDATE.BAT
  • C:\Shares\test\DEPLOY.BAT

NAS (Destination via Sync)

  • /data/test/UPDATE.BAT (accessible as T:\UPDATE.BAT from DOS)
  • /data/test/DEPLOY.BAT (accessible as T:\DEPLOY.BAT from DOS)

COMMON/ProdSW (Also Synced)

  • T:\COMMON\ProdSW\UPDATE.BAT (backup copy)
  • T:\COMMON\ProdSW\DEPLOY.BAT (deployment script)
  • T:\COMMON\ProdSW\NWTOC.BAT
  • T:\COMMON\ProdSW\CTONW.BAT
  • T:\COMMON\ProdSW\STAGE.BAT
  • T:\COMMON\ProdSW\REBOOT.BAT
  • T:\COMMON\ProdSW\CHECKUPD.BAT

Purpose

UPDATE.BAT at Root (T:\UPDATE.BAT)

  • Purpose: Quick access backup utility from any DOS machine
  • Usage: Can run T:\UPDATE from any machine without changing directory
  • Function: Backs up C: drive to T:%MACHINE%\BACKUP\

DEPLOY.BAT at Root (T:\DEPLOY.BAT)

  • Purpose: One-time deployment installer accessible from boot
  • Usage: Run T:\DEPLOY to install update system on new/re-imaged machines
  • Function: Installs all batch files, sets MACHINE variable, configures AUTOEXEC.BAT

Benefit: Both utilities are accessible from T: drive root, making them easy to find and run without navigating to COMMON\ProdSW\


Sync Verification

Sync Run: 2026-01-19 12:55:14 Result: SUCCESS

2026-01-19 12:55:40 : Syncing UPDATE.BAT...
2026-01-19 12:55:41 :   Pushed: UPDATE.BAT
2026-01-19 12:55:41 : Syncing DEPLOY.BAT...
2026-01-19 12:55:43 :   Pushed: DEPLOY.BAT

Both files successfully pushed to NAS root directory.


Sync Schedule

  • Frequency: Every 15 minutes
  • Scheduled Task: Windows Task Scheduler on AD2
  • Script: C:\Shares\test\scripts\Sync-FromNAS.ps1
  • Log: C:\Shares\test\scripts\sync-from-nas.log
  • Status: C:\Shares\test_SYNC_STATUS.txt

Files Now Available on DOS Machines

From Root (T:)

T:\UPDATE.BAT    - Quick backup utility
T:\DEPLOY.BAT    - One-time deployment installer

From COMMON (T:\COMMON\ProdSW)

T:\COMMON\ProdSW\NWTOC.BAT      - Download updates
T:\COMMON\ProdSW\CTONW.BAT      - Upload changes (v1.2)
T:\COMMON\ProdSW\UPDATE.BAT     - Backup utility (copy)
T:\COMMON\ProdSW\STAGE.BAT      - Stage system files
T:\COMMON\ProdSW\REBOOT.BAT     - Apply staged updates
T:\COMMON\ProdSW\CHECKUPD.BAT   - Check for updates
T:\COMMON\ProdSW\DEPLOY.BAT     - Deployment installer (copy)

Deployment Workflow

New Machine Setup

  1. Boot DOS machine with network access
  2. Map T: drive: NET USE T: \\D2TESTNAS\test /YES
  3. Run deployment: T:\DEPLOY
  4. Follow prompts to enter machine name (e.g., TS-4R)
  5. Reboot machine
  6. Run initial download: C:\BAT\NWTOC

Quick Backup from Root

T:\UPDATE

No need to CD to COMMON\ProdSW first.


Testing Recommendations

Test Root Access

From any DOS machine with T: drive mapped:

T:
DIR UPDATE.BAT
DIR DEPLOY.BAT

Both files should be visible at T: root.

Test Deployment

On test machine (or VM):

T:\DEPLOY

Should run deployment installer successfully.

Test Quick Backup

T:\UPDATE

Should back up C: drive to network.


Maintenance Notes

Updating Scripts

  1. Edit files in D:\ClaudeTools\
  2. Run: powershell -File D:\ClaudeTools\copy-root-files-to-ad2.ps1
  3. Files copied to AD2 root: C:\Shares\test\
  4. Next sync (within 15 min) pushes to NAS root
  5. Files available at T:\ on DOS machines

Monitoring Sync

# Check sync log
Get-Content \\192.168.0.6\C$\Shares\test\scripts\sync-from-nas.log -Tail 50

# Check sync status
Get-Content \\192.168.0.6\C$\Shares\test\_SYNC_STATUS.txt

Change History

Date Change By
2026-01-19 Added DEPLOY.BAT to root-level sync Claude Code
2026-01-19 UPDATE.BAT already syncing to root (Existing)

Status: COMPLETE AND TESTED Next Sync: Automatic (every 15 minutes) Files Available: T:\UPDATE.BAT and T:\DEPLOY.BAT