マウントしているPSTファイル一覧をPowerShellで出力

OutlookでPSTファイルを使用している環境で、
ユーザーがどの程度使用しているか実態を把握したい場合があります。

この場合、以下のPowerShellコマンドで出力可能です。

$Olk = New-Object -comObject Outlook.Application;
$Olk.Session.Stores | where{($_.FilePath -like '*.pst')} | ft DisplayName,FilePath -Autosize;

ログオンスクリプトなどに組み込んで共有ファイルサーバーにテキスト出力するなどすれば
ユーザーに紐づいて情報が入手できます。

AD時刻同期への考慮

AD環境では、ドメイン上のすべてのコンピューターでKerberos認証を行うため、
クライアントはドメインコントローラーと同じ時刻である必要があります。
何らかの理由で時刻が5分以上ズレた場合、ログインすることができません。
この場合は手動でクライアントの時刻を修正し、ズレを5分以内にする必要があります。

ドメイン内の時刻は、PDCエミュレーターの役割を持つドメインコントローラーがマスターとなります。
時刻同期は以下のような順序を取ります。

1. PDCエミュレーターのドメインコントローラー
  ↑(参照)
2. PDCエミュレーター以外のドメインコントローラー
  ↑(参照)
3. メンバーサーバー、クライアント

メンバーサーバー、クライアントはあくまで認証先のADサーバーを参照します。
マルチドメイン環境の場合は、フォレストルートドメインをマスターとして、ドメイン階層に従って反映されます。

このような構成を取るため、PDCエミュレーターのドメインコントローラーに対しては、
時刻同期元となるNTPサーバーの指定が必要です。
以下のコマンドを実行することで設定することができます。
w32tm /config /manualpeerlist:timeserver /syncfromflags:manual /reliable:yes /update
※ timeserverには任意のNTPサーバーを指定してください。
※ 単一障害点とならないよう、NTPサーバーは複数指定するべきです
※ 複数指定する際はダブルクォートで括ります「/manualpeerlist:”timeserver01 timeserver02″」

設定後、w32timeサービスを再起動することで設定を反映させます。
net stop w32time
net start w32time

同期の状態を確認するには、以下のコマンドが必要です。
w32tm /query /source

--
構成変更や障害などでPDCエミュレーターの役割を移動させた場合でも、
時刻同期の設定は自動的に反映されません。
切替を実施した際は、手動で時刻動機設定を再度実施する必要があります。

改元が行われる際のシステム影響

こんな記事を見つけました。

改元が行われた際の Exchange Server への影響について
https://blogs.technet.microsoft.com/exchangeteamjp/2017/08/24/impact-on-exchange-when-new-era-starts/

確かに天皇陛下も退位の意向を示しているわけで、
このような話題も出てくるのだなと感心してしまいました。
よくよく考えてみれば前回は約30年前なのですね。

普段自分が設計/構築するシステムではあまり影響が無いように考えていたのですが、
帳票関連などやられている方はテンプレートなどの修正/差し替えが大変そうですね。

どうしても譲れない仕様であるならばともかく、基本的にシステムは
外乱に影響されず拡張性/保守性を高めた構成であるべきだと強く思いました・・・・。

Outlookのキャッシュファイルを自動削除

OutlookをExchange環境でする場合、
キャッシュモードでの使用が推奨されています。

キャッシュモードが有効だと、Exchangeメールボックスの容量に応じて
クライアントローカルにキャッシュファイルが保存されるのですが
複数人で使用するクライアントですとHDDを圧迫しかねません。

グループポリシーのスタートアップスクリプトに組み込むことで
一定日数が経過したキャッシュファイルを削除してくれるスクリプトを書いてみました。

# 変数定義
$OST_Path01 = "C:\Users\";
$OST_Path02 = "\AppData\Local\Microsoft\Outlook\";
$File_Extension = "*.ost";
$Number_Of_Days = 30;

# メイン
$Folder_List = Get-ChildItem -Path $OST_Path01;

foreach($tmp01 in @(Get-ChildItem -Path $OST_Path01)){
    $File_Path = $OST_Path01 + $tmp01.Name + $OST_Path02;

    if(Test-Path -Path $File_Path){
        foreach($tmp02 in @(Get-ChildItem -Path $File_Path -Recurse -Force -Include $File_Extension)){
            $Item_Property = Get-ItemProperty -Path $tmp02.FullName;
            if(((Get-Date) - $Item_Property.LastWriteTime).days -gt $Number_Of_Days){
                Write-EventLog -LogName Application -Source Application -EventID 999 -EntryType Information -Message "PowerShell Script Run.";
                Remove-Item -Path $tmp02.FullName -Force;
            }
        }
    }
}

スクリプトではデフォルトパスを想定し、30日以上更新がないOSTファイル(キャッシュファイル)を
自動的に削除します。この際、削除されたことがわかりにくいのでアプリケーションログに書き込んでいます。
Windowsのユーザープロファイルも含め、使用するには環境に応じたカスタマイズが必要かもしれません。

PowerShellでローカルプロファイルを削除

不特定多数者が使用する端末などですと、
知らぬ間にローカルプロファイルでディスクが一杯に・・・なんてこともありがちです。
PowerShellで条件を設定しながら削除することが可能です。
スクリプトを作成してスタートアップスクリプトなり、タスクスケジューラに
設定してあげるとシステム管理者が幸せになれるかもしれません。

Get-CIMInstance win32_userProfile -verbose | where{$_.LastuseTime -let $(Get-Date).Date.AddDays(-90)} | Remove-CIMInstance -Verbose;

上記コマンドでは、「LastUseTime」(GUI画面だと変更日)を軸としてコマンドの実行日から90日以上更新がないプロファイルを削除します。
数値を変更することで、期間は柔軟に変更可能です。
所謂「既定のプロファイル」はアクセスが拒否されますので削除される恐れはありません。
このままだとエラーが表示されてしまうので、除外したほうがスマートですね。

Get-CIMInstance win32_userProfile -verbose | where{($_.LastuseTime -let $(Get-Date).Date.AddDays(-90)) -and ($_.SID -ne "S-1-5-18")} | Remove-CIMInstance -Verbose;

これで綺麗に削除されるはずです。

PowerShellでFSMO移動

普段はGUIやコマンドプロンプトから実施することが多いのですが、
PowerShellでのやり方を調べてみました。

1. ActiveDirectory向けモジュールを読み込む

Import-Module ActiveDirectory;

2. FSMOを転送する

Move-ADDirectoryServerOperationMasterRole -Identity 移動先ADサーバー -OperationMasterRole 0,1,2,3,4 -Confirm:$False; 
    # OperationMasterRole
    # 0:PDCEmulator
    # 1:RIDMaster
    # 2:InfrastructureMaster
    # 3:SchmeMaster
    # 4:DomainNamingMaster

「OperationMasterRole」の指定で転送する操作マスタ選択できます。
また、「-Confirm:$False」を入れることで実行確認メッセージをスキップしています。

上記例では数字で指定していますが、明示的に機能名で指定することも可能です。

Move-ADDirectoryServerOperationMasterRole -Identity 移動先ADサーバー -OperationMasterRole InfraStructureMaster,RIDMaster,PDCEmulator,DomainNamingMaster,SchemaMaster -Confirm:$False;

なお、「-Force」オプションを加えることで、AD同士の疎通が取れない中でのFSMO強制転送が可能です。

Move-ADDirectoryServerOperationMasterRole -Identity 移動先ADサーバー -OperationMasterRole 0,1,2,3,4 -Force -Confirm:$False; 

Kerberosチケット情報を確認する

WindowsのコマンドでKerberosチケット情報を確認する際のメモ。
klistコマンドを使用することでクライアントに払い出されているチケット情報を確認できます。

【コマンド】
klist (-lh/-li/tickets/tgt/purge)

-lh/-li:確認対象のログオンIDを指定するときに使用
tickets:現在キャッシュされているTGTと、各種サービスチケットを一覧表示
tgt:最初のTGTを表示
purge:すべてのチケットを削除

・ ticketsオプション使用時の表記
現在のログオンID:ログオンしているユーザーのID(LUID)
クライアント:クライアント名を表示
サーバー:サービス名とサービスを提供するサーバーを表示
Kerberosチケットの暗号化の種類:Kerberosチケットを暗号化するために使用される暗号化形式
チケットのフラグ:Kerberosのチケットフラグ(詳細は割愛)
開始時刻:チケットが有効となる時刻
終了時刻:チケットが無効となる時刻(この時刻を過ぎたチケットはサービスの認証や更新に使用不可)
更新期限:新しい初期認証が必要となる時刻
セッションキーの種類:セッションキーに使用される暗号化形式

Windowsのイベントログについて

各イベントログでは、イベントを保存するパス、サイズを指定することができ、
サイズは1028より大きい値で64KB単位で設定する必要があります。
最大値は18014398509481983KB、実質的には気にしないで良いというレベルですが
実際に記録できるかどうかは不明です。
※ Windows7で確認
機器の性能にも依存しますが、最大でも数GB程度に収めたほうが可読性が高いと思います。
問題発生時に見ることができなければ意味がありませんからね。

ログサイズは64KB単位で増加します。このため、あまり更新頻度の高くないログでは
記録数が異なるにも関わらずログファイルのサイズが同じである場合もあります。

イベントログサイズが最大値に達した際は、以下の3つから動作を選択できます。

  • 必要に応じてイベントを上書きする(最も古いイベントから)
    既定値。設定された最大サイズの中で古いイベントから上書きして
    常に最大ログサイズをキープします。別途ログ管理システムなどを
    用意しているのでなければ、この設定が無難かと思います。
  • イベントを上書きしないでログをアーカイブする
    設定された最大サイズに達すると、自動的にアーカイブとして別ファイルに退避されます。
    退避されたログファイルは自動的に消去されることは無いため、別途ログ管理/消去の仕組みが必要です。ログ出力が多いシステムや、長期間のログ保存が求められる場合に有用です。
    ユーザーのログオン管理などでセキュリティログに適用する場合などがあるかもしれません。
  • イベントを上書きしない(ログは手動で消去)
    設定された最大サイズに達すると、ログの記録を停止します。
    手動でログを削除すると、記録を再開できます。(あまり設定するメリットはないかも)

最大ログサイズを変更する場合、大きくする場合は特に気にせず変更する事ができます。
小さくする場合は注意が必要です。現在記録されているログサイズが設定したい値を超えていた場合、以下のようなダイアログが表示され、一度ログデータの消去を求められます。
ログの欠損を憂慮するのであれば、ログのエクスポートをするなど対処が必要です。

Outlook2013でGUIを制御

Outlookに限りませんが、画面の特定項目をグレーアウトさせたいなど
細やかな制御を要求される事があります。

結論から言うと、グループポリシーで制御は可能です。
ただし、管理は非常に煩雑となるため、どうしても必要な項目のみに絞って制御すべきです。
※ 本制御はOutlook2013で確認しています
※ Outlookのグループポリシー向けに管理用テンプレートを導入している必要があります

【設定内容】
グループポリシーで、以下項目から設定します。
ユーザーの構成 > ポリシー > 管理用テンプレート > Microsoft Outlook 2013
> ユーザーインターフェイスの項目を無効にする > ユーザー設定
> コマンドバーボタンおよびメニュー項目を無効にする

オフィス製品のGUI項目には内部的にIDが設定されており、
IDをグループポリシーで指定することで無効化(グレーアウト)することができます。
正直なところ日本語での細かい資料は無く、Microsoftが出しているID表を元に
突き合わせをしていくイメージです。

Office 2013 Help Files: Office Fluent User Interface Control Identifiers
https://www.microsoft.com/en-us/download/details.aspx?id=36798

上記サイトからリストをダウンロードし、英語のGUI項目とIDが並ぶ中、対象を探していく事になりますが
Outlookは画面遷移が多いためか非常に沢山のファイルに分かれています。
WordやExcelなどは1ファイルなのでわかりやすいかもしれません。

ファイルを開くと、以下のような列で管理されています。
・ Control Name:制御対象メニューの内部名?
・ Control Type:制御対象メニューの形式?(buttonやtoggleButtonはわかりやすい・・・)
・ Tab:どのタブに存在するか(TabHome > ホームタブなど)
・ Policy ID:グループポリシーに設定するID番号
※ 色々列はありますが、上記だけでもアタリはつけられるかと思います

名前とタブなどから対象の制御メニューを推測し、グループポリシーにID番号を登録していきます。
ユーザーポリシーですので、ログオフ/ログオンで反映されます。
グループポリシーに登録できるのはID番号だけですので、コメントなどは入力できません。
このため、何の制御を実施しているのかなどは別途管理資料などで整理することになります。
複雑な管理になればなるほどExcelなど別資料管理が煩雑になります・・・・・。

今回は特別な事情でやむにやまれず、という中で設定したのですが
なるべくならば控えたほうが管理者側は気が楽です。
上記リストは製品のSPなどが出る度に更新されそうですので、更新情報にも気を配ったほうが良さそうです。

パフォーマンスモニタのログを変換

パフォーマンスモニタでログを取得する場合、よく使用するのがバイナリ形式とCSV形式です。
それぞれにメリットがあるのですが、1つのサーバーに対して両方取得するのは負荷の面からも懸念されます。

このような場合、Windows標準のコマンド「relog」を使用してログ形式の変換が可能です。

【バイナリ形式 > CSV形式】
relog Source.blg -o Destination.csv -f CSV

【CSV形式 > バイナリ形式】
relog Source.csv -o Destination.blg -f BIN

-oの後に、出力先ファイルパスを記載します。
-fの後に、出力するファイル形式を記載します。(CSV|TSV|BIN|SQL)