ソフトウェアのインストール中に通常の（非管理者）ユーザーをロックアウトする方法は？

Windows Embedded Standard 7を実行するシンクライアントと、それらを管理するSCCM 2012 R2サーバーが多数あります。シンクライアントは書き込みフィルターを有効にしているため（FBWF）、マシンの変更は永続的ではありません。まれに、それらの何かを更新する必要がありますが、SCCMを介して展開するだけで、変更をコミットするために書き込みフィルターを自動的にオフ/オンにします。

ここでは何べきで起こる：
SCCMクライアントは、ユーザーと自分の仕事を保存し、システムをオフに取得するために30分間のカウントダウンに通知します。次に、シンクライアントが再起動し、書き込みフィルターが無効になります。ログオン画面には南京錠が表示され、ユニットがサービス中であることがわかります。また、SCCMが実行している間、通常の（非管理者）ユーザーはログオンできません。SCCMが完了すると、書き込みフィルターが再び有効になり、再起動して、ユーザーが再度ログインできるようになります。

私が抱えている問題は、近接カードリーダーを使用してシステムにログインすることです。従業員はパスワードを入力しません。バッジをタップするだけです。このシステムは優れていますが、それを実行するソフトウェアはWindows Embeddedの書き込みフィルターの自動化を壊します。

ここで何が実際に起こる：
SCCMクライアントは、書き込みフィルタをオフにして再起動する前に、通常の15分の通知を行います。再起動すると、通常のログイン画面が表示されます。ユーザーは、SCCMがソフトウェアをインストールしている間にシステムにログインして使用できます。また、ユーザーセッションがアクティブであるため、書き込みフィルターをオンにして再起動する前に、再度30分間の通知が行われます。

このシナリオでは、展開時間に余分な30分を追加するだけでなく、通常のユーザーは、シンクライアント上で30-60分の無保護時間を確保できます。書き込みフィルターが再びオンになります。

この問題は、Windows Embedded 7が通常のWindows 7とは異なる資格情報プロバイダー（別名GINA）を使用しているが、SSO製品が機能するためにWindows資格情報プロバイダーを置き換える必要があるという事実に起因します。私はそれについてベンダーに連絡しましたが、彼らはそれが既知の問題であり、それに対する修正または回避策がないと言うだけです。

だからここに私の質問があります：
どうすれば目的の動作を別の方法でシミュレートできますか？特定のユーザーグループへのローカルログオンを拒否できるグループポリシー設定があることを知っています。私は、インストールの前後に対応するレジストリ設定を反転できると考えていましたが、他のアイデアを受け入れています。

必要に応じて、インストールのスクリプトを記述していません。スクリプティング、PowerShell、VBScriptなどに堪能です。これを解決するための素晴らしいアイデアを誰かが持っているのでしょうか。

更新：
これらのデバイスは、スタッフが患者のカルテを作成するために病院環境で使用されていることに言及していませんでした。これらは24時間利用可能でなければならないため、ログオン時間を制限したり、メンテナンスウィンドウを構成したりすることはできません。私たちはシフトの監督者に事前に通知することでダウンタイムを管理しますが、1時間以上かかるものは法的なコンプライアンスの問題になり、公式のダウンタイム手順を有効にする必要があります。

私たちが進む前に、私はあなた自身よりも一般読者の利益のために、つまらないポイントを作りたいと思います。

SCCM経由でプッシュするだけです

SCCMはプルベースのテクノロジーです。私はあなたが何を意味したか知っていますが、ティア1の人たちと一緒に、SCCMはプッシュベースのテクノロジーではないことを強調するあらゆる機会が、彼らがそれをより速く理解するのに役立つと思います。

私はそれについてベンダーに連絡しましたが、彼らはそれが既知の問題であり、それに対する修正または回避策がないと言うだけです

この問題の原因は埋め込みカード認証プログラムにあるように思えるので、それはあまりにも悪いです。ベンダーに注意してください。多分彼らは実際にソフトウェアを修正するでしょう。

本当の答えに-私はあなたのためにいくつかの可能な解決策を見つけましたが、どれも特に良いものはありません。

• これらのクライアントのメンテナンスウィンドウを設定して、最初の再起動でクライアントを書き込みフィルターから削除し、実際のペイロードと結果の再起動がすべて、従業員が端末にいない時間に行われるようにします。これは、最も痛みの少ないオプションのようです。SCCMをそれ以上に複雑にする必要はありません。
• ログオン拒否ユーザー権利にセキュリティグループを追加するローカルグループポリシーテンプレートを作成し、アプリケーション展開の一部として割り当て/割り当て解除します。
• PowerShellを使用して、ログオン拒否ユーザー権利を設定します。私は信じていPowerShellのコミュニティの拡張機能（PSCX）がありSet/Get-Privilegesますが、ユーザー権利の割り当てを操作できるようになるコマンドレットを
• 必要に応じてAPIを使用できます。以下に例を示します。

タスクシーケンスを使用してこれを処理する可能性について誰も触れていないようですので、利点をリストしてみましょう（一般的にそれらに精通していないと仮定しますが、読んでいても読んでください）：

インストールおよび構成したすべてがSCCMで処理される場合は、タスクシーケンスを使用してこれを実現できるはずです。主にOSDの場合、TSの使用はOSD だけでなく、次の利点を提供できます。

ワークステーションへのログオンなし

TSはwinlogon.exeが実行される前に実行されるため、ログオンウィンドウがないため、ユーザーが誤ってログオンする可能性はありません。それは私の2番目のポイントに私をもたらします：

カスタム背景画面

メンテナンスが実行されていることを示すスプラッシュスクリーン、または本当に言いたいことは何でも提供できます。

TSは実際には単なる見栄えの良いスクリプトですが、多くの機能を備えており、開発時間を短縮するようにまとめられており、OSD以外のユースケースが見つかりました。

必要なことを実行するためのスクリプトが既に用意されているように思えるので、最小限のデバッグでTSに入れて作業を開始できるはずです。

SSOソフトウェアがActive Directory資格情報を使用するかどうかを指定していないため、解決策はActive Directoryの「ログオン時間」機能を使用することです。これはユーザーごとのレベルですが、Powershellで簡単にスクリプト化できます（これは一例です）。基本的に、SCCM更新ウィンドウでログオン時間を「拒否」に設定すると、SCCMが実行している間、ユーザーはクライアントにログインできなくなります。ログアウトする最初の強制再起動が必要になります（ログイン時間機能はログインしているユーザーでは機能しません）が、そうでなければ実装するのは簡単です。

これをテストして、動作するかどうか確認してください。

SCCMアクティビティの開始時のスクリプトは、次を実行します。

• NT AUTHORITY \ Authenticated Users IDをローカルユーザーグループから削除します
• ローカルユーザーグループからNT AUTHORITY \ Interactive identityを削除します
• ローカルユーザーグループからドメインユーザーグループを削除する

最後に：

削除したセキュリティプリンシパルをローカルユーザーグループに追加し直します

追加/削除する実際のグループは、コンピューターの現在の構成方法によって異なります。

もう少しトレイルパークのように、SCCMアクティビティの開始により、logoff.exeへのショートカットをAll Users Start Menu \ Startupフォルダー（通常はC：\ ProgramData \ Microsoft \ Windows \ Start Menu \ Programs \ StartUp）にコピーできます。これには、セッションがログオンするとすぐにセッションからログオフするという効果があります。安全のために、起動/シャットダウンスクリプトを使用してそのショートカットを削除することができます。（ログオン中にShiftキーを押し続けると、スタートアップショートカットがバイパスされる可能性があると思います）。