[PowerShell] テキストファイルをバイト単位で切り出す


スポンサーリンク


PowerShell にてテキストファイルを読み込み、バイト数単位で文字列を切り出すサンプルスクリプトを作成しました。

ファイル名: get_SubstringByByte.ps1

function Get-SubStringBytes($f_text, $f_start, $f_Len) {
    $enc = [System.Text.Encoding]::Default
    $bytes = $enc.GetBytes($f_text)
    return $enc.GetString($bytes, $f_start, $f_Len)
}

function main_proc()
{
    if ($script:args.length -ne 1) {
        Write-Host "第1引数に入力ファイル名を指定してください。"
        return -1
    }

    $input = $script:args[0]
    
    $i = 0
    Get-Content $input | foreach {
        $i++
        Write-Host ([string]$i + "行目: " + $_)
        Write-Host (" --> 1~4バイトを抽出: " + (Get-SubStringBytes $_ 0 4))
        Write-Host (" --> 3~8バイトを抽出: " + (Get-SubStringBytes $_ 2 6))
    }
    
    return 0

}

# 処理開始
$ret = main_proc

if ($ret -eq 0) {
    exit 0
} else {
    exit 1
}

 

上記スクリプトを get_SubstringByByte.ps1 として保存し、試しに実行した結果は以下の通りです。

C:\test> type TEST.txt   ・・・ (1)
1234567890
1234567890
C:\test> powershell -ExecutionPolicy RemoteSigned .\get_SubstringByByte.ps1 TEST.txt  ・・・ (2)
1行目: 1234567890
 --> 1~4バイトを抽出: 1234
 --> 3~8バイトを抽出: 345678
2行目: 1234567890
 --> 1~4バイトを抽出: 12
 --> 3~8バイトを抽出: 234

C:\test>

各行の説明
(1) 抽出するテキストファイルの全体を表示。
(2) get_SubstringByByte.ps1 を実行。


[Windows] Windows Server 2012 以降でIPv4 アドレスが返される順番について

Windows Server 2012 や Windows Server 2012 R2では、2 つ以上の IP アドレスを持っている場合、バインド順やメトリックを変更しても使用する IP アドレスを変更できない、という仕様があります。

詳細は以下のサイトに記載されています。

マルチホーム環境にて API により IPv4 アドレスが返される順番について
http://blogs.msdn.com/b/japan_platform_sdkwindows_sdk_support_team_blog/archive/2015/01/09/api-ipv4.aspx

 

「使用する IP アドレスを変更できない」とは、OSI 参照モデルで 3 層 (ネットワーク層) はルーティングに従うため、スタティックルートの追加等で動作を制御することが可能ですが、7 層 (アプリケーション層) で gethostbyname 関数や getaddrinfo 関数を使用しているソフトウェアがあれば、その際に仕様する IP アドレスを明示的に変更できない、という意味になります。

バインド順やメトリックを変更してもダメ、ということは仕様なので仕方がないとしても、それなら、そもそもどんな順番で IP アドレスを選択しているのか?、という疑問が出てきます。

で、検証してみました。
その結果は、「後で追加した NIC (アダプター) が優先される」という規則があるようです。

但し、NIC チーミングで作成した仮想 NIC (アダプター) を再作成しても、この法則に当てはまらないこともあり、よく分からない。。。という結論です。

この規則を逆手にとって、明示的に使用したい IP アドレスがあれば、そのアダプターを後で作成する(すでに作成しているのであれば再作成する or IP アドレスをアダプター間で入れ替える) ことで解決策とできる可能性があります。

確実な回避策としては、LAN ケーブルを差し替え、IP アドレスも入れ替える、ということになりそうですが。。

以下に NIC を追加した際に PowerShell の GetHostByName がどの順番で、IP アドレスを返すか検証した結果を記述していきます。

Ethernet0 と Ethernet1 の 2 つのアダプターが存在し、アダプターは Ethernet0 を先に作成し、Ethernet1 を後に作成しています。

C:\> ipconfig

Windows IP 構成


イーサネット アダプター Ethernet0:

   接続固有の DNS サフィックス . . . . .:
   IPv4 アドレス . . . . . . . . . . . .: 192.168.152.130
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: 192.168.152.2

イーサネット アダプター Ethernet1:

   接続固有の DNS サフィックス . . . . .:
   IPv4 アドレス . . . . . . . . . . . .: 172.168.152.111
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .:

C:\>

 
Powershell で GetHostByName を使用して IP アドレスを返す順番を確認すると、Ethernet1 が最初に返されています。

PS C:\> [System.Net.DNS]::GetHostByName("") | foreach { $_.AddressList.IPAddressToString }
172.168.152.111
192.168.152.130
PS C:\>

 
この状態でも、後で追加したアダプターが 1 番目に取得されていることが確認できますが、さらに 3 つ目のアダプター Ethernet2 を追加し、バインド順は一番最後 (3番目) にします。

C:\> ipconfig

Windows IP 構成


イーサネット アダプター Ethernet0:

   接続固有の DNS サフィックス . . . . .:
   IPv4 アドレス . . . . . . . . . . . .: 192.168.152.130
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: 192.168.152.2

イーサネット アダプター Ethernet1:

   接続固有の DNS サフィックス . . . . .:
   IPv4 アドレス . . . . . . . . . . . .: 172.168.152.111
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .:

イーサネット アダプター Ethernet2:

   接続固有の DNS サフィックス . . . . .: localdomain
   リンクローカル IPv6 アドレス. . . . .: fe80::4474:79fc:b42a:938e%18
   IPv4 アドレス . . . . . . . . . . . .: 192.168.152.134
   サブネット マスク . . . . . . . . . .: 255.255.255.0
   デフォルト ゲートウェイ . . . . . . .: 192.168.152.2

C:\>

 
Powershell で GetHostByName を実行すると、バインド順が最後の Ethernet2 が一番最初に返されていることが分かります。

PS C:\> [System.Net.DNS]::GetHostByName("") | foreach { $_.AddressList.IPAddressToString }
192.168.152.134
172.168.152.111
192.168.152.130
PS C:\>

 
以上、Windows Server 2012 以降でIPv4 アドレスが返される順番について、でした。


[Windows] 「このフォルダーにアクセスする許可がありません。」とダイアログが表示され、「続行」を押すと自分自身のアクセス権限が付与される事象について

発生事象

Windows Server 2012 R2 等で、Explorer であるフォルダを開こうとすると、以下のようなダイアログが表示されることがあります。

20150615_01
 
「続行」ボタンを押すと、以下のようにアクセスしたユーザー (この場合は adminuser) のアクセス権が勝手付与されてしまいます。

20150615_01a
 
ちなみに、adminuser はドメインの administrators グループに所属しており、このフォルダ (test_folder) には権限を持っています。

20150615_03

原因と解決策

以下の 3 つの条件をいずれとも満たす場合、この事象が起きます。

  1. UACが有効。
  2. Users グループへのアクセス権限が付与されていない。
  3. BUILTIN の administrator 以外のユーザーを使用している。

 
ということで、上記いずれかの条件を満たさないようにすれば、本事象が発生しません。

UAC を無効にする、または、Users グループ権限を付与する、というのは解決策・回避策としてはイマイチなので、BUILTIN の administrator を使用したほうが無難です。


[Windows] Windows タスクでバッチを実行すると環境変数 HOMEDRIVE や HOMEPATH が設定されない

Windows タスクからバッチを実行すると HOMEDRIVE や HOMEPATH など、一部の環境変数がセットされないことに気付きました。

さらに、Windows タスクではセットされない環境も、そのタスクを実行するユーザーでログインしておけば、Windows タスクで環境変数がセットされることも分かりました。

ここまで読んでもらっても、よく伝わらないと思いますので、Windows Server 2012 R2 で検証した結果を以下に整理します。

set コマンドのみを実行する set.bat を作成し、以下のようにタスクを作成しました。

20150525_01
 
検証および比較したパターンは以下の 3 つです。

  1. Windows Server 2012 R2 に administrator でログインし、コマンド・プロンプトを起動して、set コマンドを実行。
  2. Windows Server 2012 R2 に administrator でログインし、同じ administrator で実行するWindows タスクから set コマンドを実行。
  3. Windows Server 2012 R2 に administrator でログインしていない状態で、2. のタスクをスケジュール実行。

 
検証結果は以下の通りです。

表. 相違がある環境変数
環境変数 1.ログインして直接実行 2.ログインして、Windows タスクを実行 3.ログインせず、Windows タスクを実行
APPDATA C:\Users\Administrator\AppData\Roaming C:\Users\Administrator\AppData\Roaming - (設定なし)
HOMEDRIVE C: C: - (設定なし)
HOMEPATH \Users\Administrator \Users\Administrator - (設定なし)
LOCALAPPDATA C:\Users\Administrator\AppData\Local C:\Users\Administrator\AppData\Local - (設定なし)
LOGONSERVER \\<サーバ名> \\<サーバ名> - (設定なし)
USERDOMAIN_ROAMINGPROFILE TDOMAIN ※ドメイン名 TDOMAIN ※ドメイン名 - (設定なし)
USERPROFILE C:\Users\Administrator C:\Users\Administrator C:\Users\Default

 
Windows タスクはログイン時に設定される環境変数がセットされないようです。

また、同一ユーザーで事前にログインしておくと、Windows タスクでも環境変数がセットされるようです。

以上、Windows タスクでセットされない環境変数があります、でした。


[AD] WMI フィルタの Like で Not (否定) の使い方

ADサーバーのグループ・ポリシーは適用可否を WMI フィルタで動的に判断させることが可能です。

例えば、以下の WMI を指定することで、コンピュータ名が PC1 または PC2 で始まるクライアントだけ、グループポリシーを適用させることが可能です。

SELECT * FROM Win32_OperatingSystem WHERE CSName LIKE “PC1%” OR CSName LIKE “PC2%”

では、逆にコンピュータ名 PC1 または PC2 で始まらないクライアントを対象にする場合は、WMI フィルタを以下のように記述します。

SELECT * FROM Win32_OperatingSystem WHERE NOT CSName LIKE “PC1%” And NOT CSName LIKE “PC2%”

または以下のような記述でも構いません。

SELECT * FROM Win32_OperatingSystem WHERE Not (CSName LIKE “PC1%” Or CSName LIKE “PC2%”)

以上、Like と Not を使った WMI フィルタの記述方法でした。


[ウイルスバスター] 更新モジュール (tmcm_patternupdateXXXXXXX.zip) を取得する VBScript を作成してみた

ウイルスバスターでは、更新モジュールが ZIP ファイルで提供されており、手動でパターンファイル等を更新することが可能です。

トレンドマイクロ Q&Aページ – 手動アップデートモジュール適用手順
http://esupport.trendmicro.com/solution/ja-jp/1306619.aspx?print=true

更新モジュールのファイル名は、tmcm_patternupdateXXXXXXX.zip (XXXXXXXは7桁の数値) です。

ウイルスバスター Copr.サーバがインターネットに接続できない環境でも、この ZIP ファイルをダウンロードして展開し、展開した共有フォルダをウイルスバスター Corp.サーバのアップデート元に指定することで、パターンファイル等を更新することが可能となります。

更新モジュールは週に何回か更新され、そのたびに新しい ZIP ファイルが提供されているのですが、毎回これをダウンロードするのは、とても面倒なので ZIP ファイルを取得する VBScript を作成しました。


'ウイルスパターンファイルの更新モジュールのダウンロードサイト
strTargetURL = "http://www.trendmicro.com/download/tmcm35-jp.asp"

'ダウンロードサイトHTMLの保存ファイル名
strHtmlFile = Left(WScript.ScriptFullName, InStrRev(WScript.ScriptFullName, ".") - 1) & ".html"

'----------------------------------------------------------------
' 関数: GetZipFileName
' 処理: HTTPでファイルを取得する関数
' 引数: f_strURL  - 取得先のURL
'       f_strFile - 保存ファイル名 
'----------------------------------------------------------------
Sub GetHttpFile(f_strURL, f_strSaveFile)

	'Fetch the file
	Set objWinHttp = CreateObject("WinHttp.WinHttpRequest.5.1")
	
	Wscript.Echo "HTTP GETを実行します。URL=" & f_strURL
	objWinHttp.open "GET", f_strURL, false
	objWinHttp.send()

	If objWinHttp.Status = 200 Then
		Set objADOStream = CreateObject("ADODB.Stream")
		objADOStream.Open
		objADOStream.Type = 1 'adTypeBinary
		
		objADOStream.Write objWinHttp.ResponseBody
		objADOStream.Position = 0    'Set the stream position to the start
		
		Set objFSO = Createobject("Scripting.FileSystemObject")
		
		If objFSO.Fileexists(f_strSaveFile) Then
			objFSO.DeleteFile f_strSaveFile
		End If
		
		Set objFSO = Nothing
		
		Wscript.Echo "保存ファイル名: " & f_strSaveFile
		objADOStream.SaveToFile f_strSaveFile
		objADOStream.Close
		Set objADOStream = Nothing
	
	End if

	Set objWinHttp = Nothing
	
End Sub

'----------------------------------------------------------------
' 関数: GetZipFileName
' 概要: HTMLファイルよりZIPファイルのURLを取得
' 引数: f_strURL  - 取得先のURL
'       f_strFile - 保存ファイル名 
'----------------------------------------------------------------
Function GetZipFileName(f_strHtmlFile)

	GetZipFileName = ""
	
	'読込モードでHTMLファイルを開く
	Set objFSO = CreateObject("Scripting.FileSystemObject")
	Set objTextStream = objFSO.OpenTextFile(f_strHtmlFile, 1)
	
	'HTMLファイルから正規表現でZIPファイル名を検索
	Set objReg = CreateObject("VBScript.RegExp")
	objReg.Pattern = "http://www.trendmicro.com/ftp/products/aupattern/japan_offline/tmcm_patternupdate.*\.zip"
	objReg.IgnoreCase = True
	objReg.Global = True
	
	strMatch = ""
	Do Until objTextStream.AtEndOfStream = True
		strLine = objTextStream.ReadLine
		'WScript.echo strText
		If objReg.Test(strLine) = True Then
			strMatch = strLine
			Exit Do
		End If
	Loop
	
	'~<a href="http://www.trendmicro.com/ftp/products/aupattern/japan_offline/tmcm_patternupdateXXXXXXX.zip" ~
	'から http://www.trendmicro.com/ftp/products/aupattern/japan_offline/tmcm_patternupdateXXXXXXX.zip を抽出 
	objReg.Pattern = ".*<a href=""http:"
	strMatch = objReg.Replace(strMatch, "http:")
	objReg.Pattern = "\.zip"".*$"
	strMatch = objReg.Replace(strMatch, ".zip")
	
	Wscript.Echo "最新の更新モジュール名: " & strMatch
	
	'返却値にZIPファイルのURLをセット
	GetZipFileName = strMatch
	
End Function

'更新モジュールのダウンロードサイトのHTMLを取得
GetHttpFile strTargetURL, strHtmlFile

'ZIPファイル名を取得
strZipURL = GetZipFileName(strHtmlFile)

'URLからZIPファイル名を取得
strZipFile = Right(strZipURL, Len(strZipURL) - InStrRev(strZipURL, "/"))
strScriptPath = Left(WScript.ScriptFullName, InStrRev(WScript.ScriptFullName, "\") - 1)
strZipFile = strScriptPath & "\" & strZipFile

'更新モジュールを取得
GetHttpFile strZipURL, strZipFile

 

作成した VBScript の実行例です。
トレンドマイクロのサイトから tmcm_patternupdateXXXXXXX.zip の URL を特定して、ローカルに取得しています。

C:\unyo\>cscript //Nologo get_tmcm_patternupdate_zip.vbs   ・・・ (1)
HTTP GETを実行します。URL=http://www.trendmicro.com/download/tmcm35-jp.asp
保存ファイル名: C:\unyo\\get_tmcm_patternupdate_zip.html
最新の更新モジュール名: http://www.trendmicro.com/ftp/products/aupattern/japan_offline/tmcm_patternupdate1162580.zip
HTTP GETを実行します。URL=http://www.trendmicro.com/ftp/products/aupattern/japan_offline/tmcm_patternupdate1162580.zip
保存ファイル名: C:\unyo\\tmcm_patternupdate1162580.zip

C:\unyo\>dir tmcm_patternupdate1162580.zip                 ・・・ (2)
 ドライブ C のボリューム ラベルは Windows7_OS です
 ボリューム シリアル番号は B480-4665 です

 C:\unyo\ のディレクトリ

2015/04/25  01:02       171,483,129 tmcm_patternupdate1162580.zip
               1 個のファイル         171,483,129 バイト
               0 個のディレクトリ  134,472,200,192 バイトの空き領域

C:\unyo\>

各行の説明
(1) VBScript で tmcm_patternupdateXXXXXXX.zip を取得。
(2) 取得した tmcm_patternupdateXXXXXXX.zip を確認。

 

この ZIP ファイルを展開し、そのフォルダを共有フォルダにします。
この共有フォルダをウイルスバスター Corp.サーバのアップデート元に指定すれば、ウイルスバスター Corp.サーバに更新モジュールを適用することが可能となります。


[LoadRunner] RDP プロトコルを使用して AD サーバーに負荷をかける (2/2)

前回、リモートデスクトップセッションホストのサーバーを準備したので、いよいよ今回は LoadRunner で RDP による負荷テストを実施してみます。

この章の目次と概要です。

Virtual User Generator を使用して負荷テストのシナリオを作成
  1. デスクトップ上の Virtual User Generator を実行し、メニューから「File」→「New Script and Solution」を選択します。
    Single Protocol から「RDP」を選択します。
    Script Name はデフォルトのまま「RDP1」として、「Create」ボタンを押します。
    20150319a_01
  2. 「Action」にて、以下を記述します。
    Action()
    {
    	
    	rdp_connect_server("Host=192.168.152.131", 
    		"UserName={user_list}", 
    		"Password=Zaq12wsx", 
    		"Domain=testdomain1", 
    		RDP_LAST);
    
    	rdp_sync_on_server_disconnect("StepDescription=Sync on Server Disconnect 1", 
    		RDP_LAST);
    	
    	return 0;
    }
    
    

     
    上記を記述したら、左ペインにある「Parameters」を右クリックし、「Create New Parameters…」を選択します。
    20150319a_06

  3. パラメータ名を「user_list」とし、「Proerties」ボタンを押します。
    20150319a_07
  4. 画面中央にある「Create Table」ボタンを押します。
    20150319a_08
  5. 先程のボタンが「Edit with Notepad」となるので、このボタンを押します。
    20150319a_09
  6. 以下のように、testuser01~15 を記述して保存します。
    20150319a_10
  7. testuser01~15 が登録されたことを確認します。そして、「Select next now」を「Unique」に、「Update value on」を「Each iteration」に変更後、「Simulate Parameter」ボタンを押します。
    20150319a_11
  8. 「Number of Vusers」を「5」、「Number of iterations to run」を「3」に変更し、「Simulate」ボタンを押します。
    以下のように、使用するユーザーが重複しないことを確認します。
    20150319a_11a
  9. 以上でテストシナリオの作成は完了です。
    F5 キーを押し、作成したテストを試しに実行してみます。テスト実行すると以下にように、リモートデスクトップ画面が起動し、自動的にログインが行われます。
    ログオフはグループ・ポリシーのログオンスクリプトにて行われます。
    20150319a_12
  10. テスト実行が正常終了すると以下のように、Script Passed となります。
    20150319a_13

Controller で複数スレッドのよる負荷をかける
  1. Virtual User Generator を終了し、次はデスクトップ上の Controller を実行します。
    先程作成したばかりの RDP1 を追加し、「OK」ボタンを押します。
    20150319a_14
  2. メニューから「Scenario」→「Load Generators…」を選択し、以下の画面にて「Add…」ボタンを押します。
    20150319a_15
  3. 「localhost」と入力し、「OK」ボタンを押します。
    20150319a_16
  4. localhost が追加されたら右側の「Connect」ボタンを押し、Status が「Ready」になることを確認後、「Close」ボタンを押します。
    20150319a_17
  5. Scenario Scripts 欄の「rdp1」を右クリックし、「Runtime Settings…」を選択します。
    「Run Logic」にて、「Number of Iterations」を「3」に変更し、「OK」ボタンを押します。
    20150319a_18
  6. Global Schedule 欄にて、Start Vusers を「Start 5 Vusers: 1 every ~」となるように設定を変更します。
    20150319a_19
  7. 以上で準備完了です。
    F5 キーを押して早速実行してみます。リモートデスクトップ接続を受け付けるサーバーにて、タスクマネージャーを起動し、ユーザーを確認すると、以下のように testuser01~15 のユーザーのうち、同時に 5 ユーザーが交互にログインしている様子が確認できます。
    20150319a_20

以上で、LoadRunner を使った AD サーバーの負荷テスト方法の説明は完了です。

実際に負荷テストを実施する場合は、logon.bat を見直したり、LoadRunner のパラメータの調整したりする必要があるかと思いますが、このような方法で負荷テストを実施できるかと思われます。


[LoadRunner] RDP プロトコルを使用して AD サーバーに負荷をかける (1/2)

前回、LoadRunner を導入したので、2 回に分けて、RDP プロトコルを使って AD サーバに負荷かけることを試してみます。

この章の目次と概要です。

ADサーバーの負荷テスト方法

LoadRunner サーバーとは別に RDP 接続を受け付けるリモート デスクトップ セッション ホスト の役割を有効にしたサーバーを用意します。

リモート デスクトップ セッション ホストを継続して使用するにはライセンスが必要ですが、ライセンスがなくとも 120 日使用することができます。
LoadRunner_RDP

同時 5 仮想ユーザー (5スレッド) で RDP によるログオン/ログオフを繰り返します。
※ユーザー数が 5 で十分な負荷テストになるとは言えませんが、とりあえず 5 ユーザーで負荷テストを実施してみます。

各仮想ユーザー(スレッド)は同じユーザーを使用せず、それぞれ 3 ユーザーアカウントをサイクリック (testuser01→testuser02→testuser03→戻るなど)に使用します。

リモートデスクトップセッションホストの用意

複数のリモートデスクトップ接続を受け付けるために、リモート デスクトップ セッション ホストの役割を追加したサーバーを準備します。

  1. サーバー マネージャの「管理」から「役割と機能の追加」を開始します。「次へ」ボタンを押します。
    20150314_01
  2. 「役割ベースまたは機能ベースのインストール」が選択されていることを確認し、「次へ」ボタンを押します。
    20150314_02
  3. サーバーを選択し、「次へ」ボタンを押します。
    20150314_03
  4. 「リモート デスクトップ サービス」にチェックを入れ、「次へ」ボタンを押します。
    20150314_04
  5. 機能は追加画面では、何もせずに「次へ」ボタンを押します。※後で必要な機能が自動で追加されます。
    20150314_05
  6. 「次へ」ボタンを押します。
    20150314_06
  7. 「リモート デスクトップ セッション ホスト」にチェックを入れます。
    20150314_07
  8. 「リモート デスクトップ セッション ホスト」にチェックを入れようとすると、機能追加が表示されるので、「機能の追加」ボタンを押します。
    20150314_08
  9. 「リモート デスクトップ セッション ホスト」にチェックが入っていることを確認し、「次へ」ボタンを押します。
    20150314_09
  10. 「インストール」ボタンを押し、役割と機能追加を開始します。
    20150314_10
  11. インストールが完了したら、「閉じる」ボタンを押し、OS再起動を実施します。
    20150314_11

ログイン用ユーザーの作成

ADサーバーにて 15 ユーザー (testuser01~15) を一般ユーザーとして作成します。
LoadRunner での負荷テストのシナリオ作成を簡単にするために、パスワードは 15 ユーザーとも同じ Zaq12wsx としておきます。
また、この 15 ユーザーのみに適用するグループポリシーを後で作成するために、ユーザーは TestOU に作成します。

20150314_13
 
この一般ユーザーである testuser01~15 がリモート デスクトップ セッション ホストのサーバーにリモートデスクトップでログインできるようにするため、リモート デスクトップ セッション ホストのサーバーの Remote Desktop Users グループに testuser01~15 をメンバーとして追加します。

20150314_12

テスト用グループポリシーの作成

先程作成した 15 ユーザーを含む TestOU に TestGPO というグループポリシーを作成します。

20150314_14
 

TestGPO を編集し、「ユーザーの構成」→「ポリシー」→「Windows の設定」→「スクリプト」→「ログオン」にて、logon.bat を指定します。

20150314_15
 
logon.bat には以下の 2 行を記述します。

20150314_16

これにより、ログオン後、gupdate と logoff を実行させるようにします。、

以上で準備完了です。

次に、LoadRunner にて負荷テストを実施してみます。
[LoadRunner] RDP プロトコルを使用して AD サーバーに負荷をかける (2/2)


[AD] ログオンスクリプト、ログオフスクリプトを複数のグループポリシーで設定した場合の挙動について

Default Domain Policy でログオン スクリプトが設定されている状態で、OU にリンクされてグループ ポリシーでもログオン スクリプトを設定すると、どうなるのか?という疑問があったので調べてみました。

Windows Server 2012 R2 の環境で試したところ、結論としては「両方実行される」です。

以下に検証した内容を記述しておきます。

まずは、グループポリシーを設定します。

表. グループポリシー設定例
GPO ログオン スクリプト ログオフ スクリプト
Default Domain Policy logon1.bat logoff1.bat
OU にリンクされた GPO logon2.bat logoff2.bat

結論から言えば、ログオン時は logon1.bat、logon2.bat の順で実行され、ログオフ時は logoff1.bat、logoff2.bat の順で実行されます。

テストで使用したクライアントは、コンピュータ・アカウントはデフォルトの「Computers」においたままとし、ユーザー・アカウントのみを GPO をリンクした OU に移動しました。

また、上記 4 つの bat ファイルはいずれとも以下の 1 行を記述しています。

echo %DATE% %TIME:~0,8% %~nx0 >> C:\script\logon.log

 
テスト用PCにて、C:\script フォルダを作成すれば準備完了です。

実際にログオン、ログオフしたときのログは以下の通りです。

2015/03/27 21:36:46 logon1.bat
2015/03/27 21:36:46 logon2.bat
2015/03/27 21:41:05 logoff1.bat
2015/03/27 21:41:05 logoff2.bat

 

ちなみに、gpresult /Z でスクリプトを確認すると Default Domain Policy の 1 つしか表示されないので注意してください。実際は OU にリンクされた GPO のスクリプトも実行されます。

20150327_01


[AD] Windows Server 2012 R2 にて AD / SYSVOL バージョンの不一致が表示される件について

AD / SYSVOL バージョンの不一致

Windows Server 2012 R2 の AD サーバーにて、「グループポリシーの管理」の「グループ ポリシーのモデル作成」や「グループ ポリシーの結果」を使用すると、以下のように「AD / SYSVOL バージョンの不一致」が表示されました。

20150324_01
 

ところが、gpotool.exe で確認すると正常となります。

20150324_02
 

gptool.exe /verbose コマンドで詳細を確認してみても、AD (DS version) と SYSVOL (Sysvol version) のバージョンは一致しています。

C:\> gpotool.exe /verbose
Domain: testdomain1.local
Validating DCs...
Available DCs:
WIN2012SRV.testdomain1.local
Searching for policies...
Found 3 policies
============================================================
Policy {31B2F340-016D-11D2-945F-00C04FB984F9}
Friendly name: Default Domain Policy
Policy OK
Details:
------------------------------------------------------------
DC: WIN2012SRV.testdomain1.local
Friendly name: Default Domain Policy
Created: 2014/11/24 13:15:09
Changed: 2015/02/14 16:43:54
DS version:     2(user) 3(machine)
Sysvol version: 2(user) 3(machine)
Flags: 0 (user side enabled; machine side enabled)
User extensions: [{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}]
Machine extensions: [{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}][{827D319E-6EAC-11D2-A
4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1B-2488-11D1-A28C-
00C04FB94F17}]
Functionality version: 2
------------------------------------------------------------
============================================================
Policy {6AC1786C-016F-11D2-945F-00C04FB984F9}
Friendly name: Default Domain Controllers Policy
Policy OK
Details:
------------------------------------------------------------
DC: WIN2012SRV.testdomain1.local
Friendly name: Default Domain Controllers Policy
Created: 2014/11/24 13:15:09
Changed: 2015/03/05 15:23:14
DS version:     2(user) 5(machine)
Sysvol version: 2(user) 5(machine)
Flags: 0 (user side enabled; machine side enabled)
User extensions: [{00000000-0000-0000-0000-000000000000}{CEFFA6E2-E3BD-421B-852C-6F6A79A59BC1}][{C418DD9D-0D14-4EFB-8FBF
-CFE535C8FAC7}{CEFFA6E2-E3BD-421B-852C-6F6A79A59BC1}]
Machine extensions: [{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}]
Functionality version: 2
------------------------------------------------------------
============================================================
Policy {74FFAAC5-B6DB-40D4-A9CA-40997E9FE1E6}
Friendly name: TestGPO
Policy OK
Details:
------------------------------------------------------------
DC: WIN2012SRV.testdomain1.local
Friendly name: TestGPO
Created: 2015/03/19 2:41:57
Changed: 2015/03/23 15:31:56
DS version:     4(user) 0(machine)
Sysvol version: 4(user) 0(machine)
Flags: 0 (user side enabled; machine side enabled)
User extensions: [{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}]
Machine extensions: not found
Functionality version: 2
------------------------------------------------------------
============================================================

Policies OK

C:\>
原因と対応

この事象は以下のサイトに該当する Window Server 2012 R2 のバグです。

Unexpected “AD/SYSVOL version mismatch” message in Group Policy Results in Windows 8.1 or Windows Server 2012 R2
https://support.microsoft.com/en-us/kb/2957985

 

このバグを修正するために、KB2957985 の修正プログラムを含む更新プログラム Windows8.1-KB2955164-x64.msu (KB2955164) を以下のサイトよりダウンロードして Window Server 2012 R2 に適用します。

May 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2
https://support.microsoft.com/en-us/kb/2955164

 

Windows8.1-KB2955164-x64.msu (KB2955164) の修正プログラムをインストールすると、OS 再起動が促されるので、OS を再起動します。

OS 再起動後、再度、「グループポリシーの管理」の「グループ ポリシーのモデル作成」を使用すると、以下のように「AD / SYSVOL バージョンの不一致」が表示されなくなりました。

20150324_03