Windowsの基本的なスケジュールされたタスクに関連する奇妙な問題が発生し、数週間困惑しました。これらのジョブは一部のサーバーでは実行できませんが、異なるハードウェア/ VMプラットフォームで実行されている他のサーバーでは機能します。当初、これは本番システムの1つで深く発見した問題でしたが、「すぐに使える」構成から最小限の変更で機能するように、それを単純化することができました。私は実際に5行のバッチファイルを作成して、クリーンインストールに最小限の変更を加えてこれを設定し、各テストマシンが同一であることを確認しました。
構成
動作するハードウェア
VMware、XenServer、物理HPサーバーおよびその他のモデルのDellサーバー(Poweredge R730、R720、R430)でVMを構築しました。これらのほとんどは、回転する10k/15k SASディスクを使用しますが、テストとしてRAID10のSATASSDを使用して構築したHPサーバーの1つです。
動作しないハードウェア
ただし、新しいサーバーには問題があります。これらは新しいDellPoweredgeR540です。彼らはBOSSRAID 1コントローラー(基本的にはM.2 RAID 1 SSD)を内蔵しており、PERCコントローラーを介した追加の高速ストレージとしてSAS SSD)を備えています。
問題
古いハードウェアでは、手動でトリガーするとスケジュールされたタスクが実行されていることを確認できますが、別のユーザーとして実行している場合はメモ帳が実際に開いていることはわかりません。
ただし、Poweredge R540では、タスクの開始に失敗し、エラーコード2147943726(0x8007052e)が発生します。資格情報が正しく、ユーザーアカウントが新しく作成されたにもかかわらず、これは「不明なユーザー名または不正なパスワード」エラーであると思います。
ここでは、タスクが失敗したことを示すタスク履歴を確認できます
タスクは手動で実行できず、次のセキュリティイベントがセキュリティイベントログで監査されます。
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 12/10/2018 17:30:00
Event ID: 4625
Task Category: Logon
Level: Information
Keywords: Audit Failure
User: N/A
Computer: <computername>
Description:
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: <computername>$
Account Domain: <domainname>
Logon ID: 0x3E7
Logon Type: 4
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: @@CyBAAA.....<this is a long Base 62 ID, so I've removed it in case it contains sensitive information>
Account Domain:
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC0000064
Process Information:
Caller Process ID: 0x590
Caller Process Name: C:\Windows\System32\svchost.exe
Network Information:
Workstation Name: <computername>
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: Advapi
Authentication Package: Negotiate
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
昨日、2x R540、2x VM、1x HP Serverを再構築しましたが、この障害が発生したのはR540だけでした。これは予測可能です。すべてのテストマシンの再イメージングを試みましたが、毎回結果は同じです。
その他の関連する調査結果
R540がADの「コンピューター」OUに直接組み込まれている場合、つまりR540がセキュリティベースラインポリシーを取得していない場合、R540を正しく機能させることができます。タスクは完全にインストールされ、実行されます。次に、コンピューターオブジェクトを、テストしている他のすべてのマシンと同じOUに移動すると、タスクが機能しなくなります。オブジェクトをOUからコンピューターOUに戻しても、タスクは再び機能しません。明らかに何かが変更されていますが、何が変更されているのかわかりません。また、VMや他のモデルのハードウェアではなく、この方法でR540にのみ影響する理由がわかりません。
動作中のマシンと動作していないマシンのローカルセキュリティポリシーをエクスポートして比較し、違いを確認しました。存在するものはマイナーであり、作業ポリシーセットが壊れたマシンにインポートされると、壊れたままになります。同様に、壊れたマシンから稼働中のマシンにポリシーセットをインポートしても、稼働中のマシンは破損しません。
[パスワードを保存しない]にチェックマークが付いているようにスケジュールされたタスクを変更すると、タスクは実行されますが、タスクは非ローカルリソースにアクセスする必要があるため、本番環境では機能しません。
ドメイン管理者アカウントのコンテキストで実行するようにスケジュールされたタスクを変更すると(自分自身に「バッチとしてログオン」および「サービスとしてログオン」の権限を与えている間)、「パスワードを保存しない」のチェックを外しても機能します。したがって、壊れているものは何でも、ローカルユーザーアカウントにのみ関連しているようです。
私が試した他のことは何の違いもありませんでした:
結論
何かは、これが機能しないようにするグループポリシーによって変更されている必要があると思います-おそらく何らかの形でセキュリティベースラインです。しかし、私が完全に説明できなくなっているのは、これが特定のハードウェアモデルでスケジュールされたタスクの操作を中断するだけのように見える理由です。このモデルは、同じ方法で同時に作成された作業マシンと同じ構成である必要があります。何が原因なのかわかりません。
スケジュールされたタスクまたは基本的なセキュリティ認証がハードウェア機能を使用しているかどうかを誰かが知っていますか? TPMはこれと関係がありますか?タスクの実行時にユーザーアカウントが失敗する原因となっているwhatを追跡するために他にできることはありますか?アイデアが足りなくなった。
また、誰かが尋ねた場合に備えて、コマンドラインから「runas」を実行して、作成したローカルユーザーアカウントが機能し、使用したパスワードが正しいことを証明しようとしました。
ありがとう!
この問題は、セキュリティベースラインポリシーを介してDevice Guard/CredentialGuardが有効になっていることが原因であると思われます。 Device Guardは、BIOSでセキュアブートが有効になっている場合にのみ実行されるように設定されています。つまり、そもそもセキュアブートをサポートしていないVMや古いサーバーではデバイスガードは表示されませんでした。
まったく同じ問題を示す記事がここにあります:
https://support.quest.com/kb/226489/scheduled-backups-are-not-running-on-windows-server-2016
上記の記事で述べたように、解決策は、それで十分な場合はシステムユーザーとしてタスクを実行するか、それがオプションでない場合はデバイスガードを無効にすることです。
デバイスガードを無効にしてテストしました。スケジュールされたタスクを再作成すると、BIOSでセキュアブートを有効にしたまま正常に実行されました。
これで、whyが機能しなかったことがわかりました。これで、Device Guard/Credential Guardを調べて、どのように機能するかを確認できますshouldこれらを有効にして作業し、今後のベストプラクティスは何ですか。
最終的にこの発見につながった彼の入力に対してGregAskewに感謝します!