After our scheduled maintenance window last weekend, our nightly attendance sync batch job is failing with connection reset errors. The batch job scheduling appears intact and triggers at the correct time (2:00 AM daily), but the cloud endpoint configuration seems to be refusing connections. We’re getting hundreds of employees’ attendance records stuck in queue, which is now blocking payroll processing for the current period.
Error snippet from the batch log:
BatchJob: AttendanceCloudSync [FAILED]
Endpoint: https://api.adp.com/time/v1/sync
Error: Connection reset by peer (errno 104)
Timestamp: 2025-03-13 02:00:47
Our network team claims no firewall rules changed during maintenance, but the timing is suspicious. Has anyone dealt with cloud endpoint authentication issues after ADP maintenance windows? We’re on version 2022.2 and this worked flawlessly for 8 months before the maintenance.
Based on the connection reset error and timing after maintenance, this is a multi-layered issue that requires addressing all three focus areas systematically.
Batch Job Scheduling Fix:
First, verify your scheduler’s retry configuration. Add this to your batch job properties:
job.retry.maxAttempts=3
job.retry.backoffSeconds=60
job.connection.timeout=45000
Cloud Endpoint Configuration:
The maintenance window likely updated ADP’s OAuth2 token endpoint. Update your endpoint configuration:
auth.endpoint=https://accounts.adp.com/auth/oauth/v2/token
api.endpoint=https://api.adp.com/time/v1/sync
api.version=2023-01
Note the version parameter - ADP now requires explicit API version headers post-maintenance.
Network/Firewall Rules:
The connection reset is happening because ADP rotated their cloud infrastructure IPs. You need to whitelist these new IP ranges:
- 52.21.84.0/22 (primary endpoint)
- 54.89.128.0/22 (failover endpoint)
- 34.195.0.0/16 (backup sync service)
Work with your network team to add these ranges to your egress firewall rules. The old IPs (52.20.x.x range) are being deprecated.
Additional Critical Steps:
- Update your SSL certificate trust store to include ADP’s new intermediate CA (DigiCert Global Root G2)
- Implement exponential backoff in your retry logic - start with 60 seconds, then 120, then 300
- Reduce batch size from 500 to 200 records per API call - ADP now enforces stricter rate limits
- Enable detailed logging for the authentication handshake to catch token refresh failures
- Set up monitoring alerts for connection timeouts beyond 30 seconds
After implementing these changes, manually trigger the batch job during business hours to verify connectivity before the next scheduled 2 AM run. The audit trail requirements mean you’ll also need to log all retry attempts and their outcomes for compliance reporting. This should resolve your payroll delay issue and prevent future sync failures after maintenance windows.
I work with several clients on ADP 2022.2 and we’ve seen this pattern before. The batch job scheduling configuration itself is fine, but the cloud endpoint authentication token refresh logic needs updating. After maintenance windows, ADP sometimes enables stricter token validation that requires the Authorization header format to include the token type prefix explicitly.
We had the exact same issue in January after a maintenance window. The problem was that ADP updated their cloud endpoint SSL certificates, and our batch job was using an outdated certificate trust store. The connection resets happened because the TLS handshake was failing silently. Check your Java runtime’s cacerts file if you’re running the batch job on a Java-based scheduler. You might need to import ADP’s new intermediate CA certificate. Also verify that your endpoint URL didn’t change - sometimes ADP migrates services to new hostnames during major updates.
Check if your API credentials got rotated during the maintenance. ADP sometimes refreshes OAuth tokens as part of security updates during maintenance windows. Log into your ADP admin portal and verify the client_id and client_secret under Integration Settings > Cloud API Credentials. If they changed, you’ll need to update your batch job configuration with the new credentials.
Connection resets at exactly 02:00:47 every night point to a timeout issue rather than authentication. Your batch job is probably connecting successfully but then hitting a read timeout. Check if ADP changed their API rate limits or batch size restrictions. We had to reduce our attendance records from 500 per batch to 250 after a similar maintenance update. The cloud endpoint might now be enforcing stricter limits. Try splitting your sync into smaller batches and adding retry logic with exponential backoff.