MegaRAIDのディスクのエラーカウントを取得する

サーバーのアレイコントローラでLSI社のMegaRAIDを採用しているメーカーって多いですよね。

富士通のPrimergyとかは自分でアレイ制御用のユーティリティを被せてますが、それ以外の通常の場合はLSI社標準のMegaRAID Storage Managerとか使ってディレクアレイの状態を取得します。

ただ、GUIだと開くのに時間は掛かりますし、ディスクの玉が多い場合など面倒なので、コマンドラインから一覧で出したい時とか有りますよね。

その場合の為に、コマンドラインツールとしてStorCLIが用意されているのですが、これまた一覧表示するというよりは情報をずらーっと出すだけの感じです。このままだとスクリプトでの条件付き処理をしたい場合などには利用ができない為、PowerShellを使って簡単に整形してみます。

まずは、StorCLIを適当なフォルダ(今回は C:\Program Files\StorCLI)に解凍して、winrm quickconfigでリモートからのコマンド受付を可能にした状態にして、以下のコマンドを実行します。

$status = @()
foreach ($hostname in @("server01","server02","server03")){
  $str = ""
  $i = 0
  $results = Invoke-Command -ComputerName $hostname -ScriptBlock { & "C:\Program Files\StorCLI\storcli64.exe" /c0/eall/sall show all | select-string -Pattern "State :","Media Error Count =","Predictive Failure Count =" }
  foreach ($result in $results) {
    $str += "${result} "
    if($i -gt 1){
      $str += "`n" ; $i=-1
    }
    $i++
  }
  foreach ($drive in $str -split "`n") {
    $data = -split $drive
    if($data -ne "") {
      $status += New-Object PSObject -Property @{Hostname = $hostname ;Drive = $data[1]; MediaError=$data[8]; PDFailure=$data[13]}
    }
  }
}
$status | ? {$_.MediaError -gt 0} | select Hostname,Drive,MediaError,PDFailure

すると、メディアエラーがカウントアップしているディスクのみ一覧が表示されます。

この情報を利用して、例えば単発のメディアエラーだったら無視するが、継続的に再発する場合はディスクの予防保全交換の手配をするなどの準備をすることができますね。

PowerShellからSCCMの更新を開始する

皆さん、更新プログラムの適用はどの様に実施されていますか?

直接Windows UpdateサイトやWSUSから更新する、必要な物を事前に配置しておいて手動でスクリプトでインストールするなど環境に応じて色々有るかと思いますが、SCCMから配信をされている管理者の方も多いかと思います。

SCCMから配信する場合、クライアントPCなどはある程度えいやでインストール期日を設定してしまっても良いのですが、適用順序などが決まっている場合に前のサーバ群が終わっているかのチェックをしてからインストールする必要があるなどの理由から、ソフトウェアセンターを開いて手動で適用を実施されているケースも多いのでは無いでしょうか。

大雑把な手順としては以下の様な物となります。

  1. 対象サーバにログイン
  2. ソフトウェアセンターを起動
  3. 左上のチェックボックス(全て)にチェック
  4. 右下の[インストール(N)]をクリック
  5. 失敗した物が有ったら再度チェックして実行
  6. 全部成功したら再起動

数十台のレンジであれば、Remote Desktop Connection Managerなどを利用して沢山リモートデスクトップのウィンドウを開いてポチポチしていけば何とかなるレベルですが、この方法のままでは数百台以上実施するのは難しいですよね。

今回は、この処理を簡略化していきたいと思います。メインとしては「スクリプトから実施」「リモートで実行」という2点となります。SCCMクライアントへは、WMIを使ってアクセスが可能ですので、PowerShellからこれをキックしたいと思います。

Continue reading

de:code 2017に登壇いたします

告知が直前となってしまいまして申し訳ございません。

毎年恒例となりましたMicrosoft主催の開発者&ITプロ向けのイベントであるde:code 2017に登壇します。

セキュリティトラックの中で「Active Directoryのディザスタリカバリ対策」というテーマで、いざという時にIT基盤のかなめであるActive Directoryをどう守るかについて事例を交えながらお話しできればと思っています。

既にチケットは完売しておりますが、参加される方はぜひ SC03 セッションまでお越し頂ければ幸いです。

第18回 Office365勉強会が開催されます

3/11(土) 13:00より、飯田橋のIIJセミナールームをお借りして第18回のOffice 365勉強会が開催されます。

今回のテーマは ”Identity&Security” Office 365から広がるクラウドの世界とそのセキュリティ対策 ということで、私も話を是非聴きたいと思っていた著名なスピーカーの方々をお招きしてOffice 365とそれを取り巻くセキュリティ関連の最新情報をお話しして頂く予定となっております。

既に満席になっている可能性はありますが、毎回一定数のキャンセルは発生しますので、是非キャンセル待ちに登録を頂ければと思います。

詳細は こちら をご参照下さい。

 

CSPパートナーがユーザーのAzureテナントにPowerShellで接続する

CSPパートナーがテナントを新規作成してAzureサブスクリプションを払い出した場合、CSPはユーザーテナントに対する代理管理者の権限を与えられます。この権限により、CSPはユーザーテナントの全体管理者として各種作業を代行することができます。

パートナーポータルからAzureポータルやOffice 365ポータルにも接続することができますが、PowerShellからも接続ができます。

通常アカウントと同じように、Login-AzureRmAccountでログインした後、Select-AzureRmSubscriptionにTenantIDとSubscriptionIDを指定しただけだと、Your Azure credentials have not been set up or have expired, please run Login-AzureRmAccount to set up your Azure Credentials.とエラーが表示されてしまいます。

よくよく見ると、Select-AzureRmSubscriptionの結果のContextにSubscriptionIDは入っていますが、SubscriptionNameが入っていないですね。正しく接続先の情報が渡せていないことが分かります。ここは、

Get-AzureRmSubscription -TenantId $TenantID -SubscriptionId $SubscriptionID | Set-AzureRmContext

としてあげれば、正しく接続することができるようになります。

web.configをPowerShellから変更する

Exchange Server 2013/2016では、これまでのバージョンと同じく細かいカスタマイズを行う場合やバグフィックスの為にweb.confgを直接書き換えるというシーンが比較的あります。

例)
クライアント固有のメッセージのサイズ制限を構成する
MSExchangeApplicationLogic Event 3018 in Exchange Server 2013
Exchange Server 2013 doesn’t display all OUs when it creates a new mailbox
Using security groups to set calendar permissions does not work in an Exchange resource forest

しかしながら、こちらのファイルはCUを適用する度にデフォルトの状態にリセットされます。CUは基本的に四半期に一度リリースされますので、3か月に一度設定がクリアされるという形になります。

毎回メモ帳などを利用して書き戻すというのも運用上の負担になりますし、作業漏れやミスによって障害が引き起こされる可能性もあるので、今回はその変更作業をPowerShellを利用して行いたいと思います。

web.configは中身はXMLドキュメントになりますので、Get-Contentした物を[XML]キャストすればPowerShellから普通に扱えます。例えば、KB2882961対策でOWAのweb.configのAppSettingsの欄に<add key=”UseDisabledAccount” value=”1″ />を加えたい場合、以下の様に行います。

$webConfig = "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\web.config"
$AppSetKey = "UseDisabledAccount"
$AppSetValue = "1"
$doc = [XML](Get-Content $webConfig)
$newAppSetting = $doc.CreateElement("add")
$doc.configuration.appSettings.AppendChild($newAppSetting)
$newAppSetting.SetAttribute("key",$AppSetKey);
$newAppSetting.SetAttribute("value",$AppSetValue);
$doc.Save($webConfig)

同様に、AppSettings以外のsystem.webなどの項目も書き換えられます。例えば、ActiveSyncの最大送受信サイズを20MBにするためにCASのweb.configの既存のmaxRequestLengthを書き換える場合は、

$webConfig = "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\sync\web.config"
$ObjKey = "maxRequestLength"
$NewValue = "20480"
$doc = [XML](Get-Content $webConfig)
$obj = $doc.configuration."system.web".httpRuntime.$ObjKey
if ($obj -ne $null) {
  $doc.configuration."system.web".httpRuntime.$ObjKey = $NewValue
  $doc.Save($webConfig)
} else {
  Write-Host "$ObjKey not found"
}

こんな感じです。(既存の値を変更するので、既存の値の存在チェックを入れています)

なお、同様に既存のweb.configの設定内容を確認することもできますので、書き戻しが必要かどうかチェックする際にも利用することが可能です。色々ご自分の環境に合わせてお試しいただくと良いかと思います。

AAD ConnectでExchange属性が同期されない(その2)

先日の記事を投稿したところ、友人より「GUIだと手順が面倒だし、美しくない」と優しいコメントを頂きましたので、PowerShellで書き直してみました。

これだと既存のコネクタが一時的にDisableになったりしませんし、後から自分で追加したカスタムルールということが明示できるので今後のソフトウェアのアップデートなどの際に分かりやすいかもしれません。

※こちらのスクリプトはExchangeスキーマを拡張していない環境では実施しないで下さい(参照先のルールが存在しませんので)。また、マルチドメイン環境には対応していません。

# Get Connector ID
$conID = (Get-ADSyncConnector | ? {$_.Type -eq "AD"} | select -first 1).Identifier.Guid

New-ADSyncRule `
  -Name 'Custom rule from AD(Exchange)' `
  -Description 'User object with Exchange schema in Active Directory. (without mailNickname)' `
  -Direction 'Inbound' `
  -Precedence 200 `
  -SourceObjectType 'user' `
  -TargetObjectType 'person' `
  -Connector $conID `
  -LinkType 'Join' `
  -SoftDeleteExpiryInterval 0 `
  -ImmutableTag 'Custom rule from AD(Exchange)' `
  -OutVariable syncRule

# Get attribute flow mapping from existing rule "In from AD - User Exchange"
$AttributeFlowMappings = (Get-ADSyncRule | ? {$_.Name -eq "In from AD - User Exchange"}).AttributeFlowMappings
foreach ($mapping in $AttributeFlowMappings){
  Add-ADSyncAttributeFlowMapping -SynchronizationRule $syncRule[0] $mapping
}

New-Object `
  -TypeName 'Microsoft.IdentityManagement.PowerShell.ObjectModel.ScopeCondition' `
  -ArgumentList 'mailNickname','','ISNULL' `
  -OutVariable condition

Add-ADSyncScopeConditionGroup `
  -SynchronizationRule $syncRule[0] `
  -ScopeConditions @($condition[0]) `
  -OutVariable syncRule

Add-ADSyncRule -SynchronizationRule $syncRule[0]

 

DirSyncのAADConnectへのアップグレードが失敗する(その2)

前回の投稿では、古いバージョンのディレクトリ同期ツールからAAD Connectへのアップグレードの際にエラーが出ないようにする手順について紹介させて頂きました。

しかしながら、気づかずにこちらを実施せずアップグレードをしてしまうと、結構悲惨な状態になります。[問題が発生したため、統合を完了できません – Syncronization Serviceをインストールできません。詳細については、イベントログを参照して下さい。]と表示され、アップグレードが失敗します。

ログを確認すると、

[21:38:17.249] [ 12] [ERROR] PerformConfigurationPageViewModel: Caught exception while installing synchronization service.
Exception Data (Raw): System.Exception: Synchronization Service をインストールできません。詳細については、イベント ログを参照してください。 ---> System.DirectoryServices.AccountManagement.NoMatchingPrincipalException: Group 'FIMSyncAdmins' was not found.
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Framework.AccountManagementAdapter.GetGroupBySamAccountName(String groupSamAccountName)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SynchronizationServiceSetupTask.<>c__DisplayClass9.<ValidateOrCreateSyncServiceGroups>b__8()
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ActionExecutor.Execute(Action action, String description)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SynchronizationServiceSetupTask.InstallCore(String logFilePath, String logFileSuffix)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ActionExecutor.ExecuteWithSetupResultsStatus(SetupAction action, String description, String logFileName, String logFileSuffix)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SetupBase.Install()
   --- 内部例外スタック トレースの終わり ---
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SetupBase.ThrowSetupTaskFailureException(String exceptionFormatString, String taskName, Exception innerException)
   場所 Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SetupBase.Install()
   場所 Microsoft.Online.Deployment.OneADWizard.Providers.EngineSetupProvider.SetupSyncEngine(String setupFilesPath, String installationPath, String sqlServerName, String sqlInstanceName, String serviceAccountName, String serviceAccountDomain, String serviceAccountPassword, String groupAdmins, String groupBrowse, String groupOperators, String groupPasswordSet, Int32 numberOfServiceInstances, ProgressChangedEventHandler progressChanged, NetworkCredential& serviceAccountCredential, SecurityIdentifier& serviceAccountSid)
   場所 Microsoft.Online.Deployment.OneADWizard.Runtime.Stages.InstallSyncEngineStage.ExecuteInstallCore(ISyncEngineInstallContext syncEngineInstallContext, ProgressChangedEventHandler progressChangesEventHandler)
   場所 Microsoft.Online.Deployment.OneADWizard.Runtime.Stages.InstallSyncEngineStage.ExecuteInstall(ISyncEngineInstallContext syncEngineInstallContext, ProgressChangedEventHandler progressChangesEventHandler)
   場所 Microsoft.Online.Deployment.OneADWizard.UI.WizardPages.PerformConfigurationPageViewModel.ExecuteSyncEngineInstallCore(AADConnectResult& result)

と表示されており、FIMSyncAdminsグループが存在しない為に発生したエラーだということが推測されます。

しかしながら、FIMSyncAdminsグループを作成後に[再試行]をクリックしても、[指定されたファイルが見つかりません。]というエラーが表示されて、続行できません。参照されたログファイルを見ても、続きを実施する方法は分かりません。

しかも都合の悪いことに、前のバージョンのディレクトリ同期は既にアンインストールされており、切り戻しもできません。再度インストーラーを走らせると新規インストールになってしまいます。

全てデフォルト設定で利用していた場合はそれで良いかもしれませんが、同期フィルタなどを設定していた場合はどんな設定をしただろう…?って途方に暮れてしまうこともあるかと思います。

根気強くログファイルを見ていくと、見つけました!

[21:27:25.520] [ 10] [INFO ] AnalyzeDirSyncInstallation: Backing up DirSync upgrade settings to C:\Users\syncadm\AppData\Local\AADConnect\DirSyncSettings20161214-212725.xml.

どうやら、Appdata\Local\AADConnect配下に作業ファイルとして古い設定データがxmlで保存されているようです。(syncadmはAAD Connectのインストールを実行したユーザー名ですので、皆さんの環境に合わせて読み替えて下さい)

※OUの除外設定などもきちんと残っています。

これさえ分かれば、後は並列デプロイと同じ方式で移行を継続できます。

PS C:\> cd "C:\Program Files\Microsoft Azure Active Directory Connect\"
PS C:\Program Files\Microsoft Azure Active Directory Connect> .\AzureADConnect.exe /migrate

設定ファイルをインポートする画面が出ますので、先ほどのフォルダ配下の.xmlファイルを指定します。また、[既存のサービスアカウントを使用する]のチェックボックスを外して[次へ]を選択します。
 

ここから先は通常のアップグレードと同じです。Azure ADの管理者アカウントの情報を入力し、次にオンプレミスのActive DirectoryのEnterprise Adminsのアカウント情報を入力し、最後に[インストール]を実施します。

これでインストールは完了です。インストール後の状態は、ステージングモードというエクスポートのみ行わない状態になっています。

MIISClientなどで既存のフィルタがきちんと移行されているかを確認(新しいMIISClientのパスはC:\Program Files\Microsoft Azure AD Sync\UIShell\miisclient.exeです。実行には一度ログオフが必要です)した後に、ステージングモードを解除します。

Azure AD Connectを起動し、[構成][ステージングモードの構成][次へ]を選択。Azure ADの管理者情報を入力、[ステージングモードを有効にする]のチェックボックスを外して[次へ]をクリックし、最後に[構成]をクリックします。
 

これで、無事AAD Connectの環境に移行できました。

良いAADライフを!

AAD Connect更新時のSfB属性

AAD ConnectでExchange属性が同期されない の記事でオンプレミスのExchange関連のスキーマについて記載させて頂いた所、Skype for Business(Lync)関連のスキーマについてはどうなのかと質問を頂きましたので、簡単に調べた範囲で記載したいと思います。

オンプレミスのADスキーマがSkype for Business(Lync)用の拡張がされていた場合、以下の3つの同期ルールが作成されます。

・In from AD – User Lync
対象:user
以下の属性を同期する:
msRTCSIP-ApplicationOptions
msRTCSIP-DeploymentLocator
msRTCSIP-Line
msRTCSIP-OrganatorSid
msRTCSIP-OwnerUrn
msRTCSIP-PrimaryUserAddress
msRTCSIP-UserEnabled
msRTCSIP-OptionFlags

・In from AD – InetOrgPerson Lync
対象:inetOrgPerson
以下の属性を同期する:
msRTCSIP-ApplicationOptions
msRTCSIP-DeploymentLocator
msRTCSIP-Line
msRTCSIP-OwnerUrn
msRTCSIP-PrimaryUserAddress
msRTCSIP-UserEnabled
msRTCSIP-OptionFlags

・In from AD – Contact Lync
対象:contact
以下の属性を同期する:
msRTCSIP-DeploymentLocator
msRTCSIP-Line
msRTCSIP-PrimaryUserAddress
msRTCSIP-OptionFlags

20161214_01

msRTCSIP-OrganatorSid 以外の属性では、既存のディレクトリ同期ツールにおいては無条件で(存在する場合)同期されていました。

msRTCSIP-OrganatorSid については、リソースフォレストモデルでの展開の際に利用されるものですので、AAD Connectから新規で追加された同期ルールになります。

従いまして、Exchangeの様に特に同期する対象を限定するスコープなど設定されていないため、アップグレード前後で同期属性が変化することは、Skype for Business Serverをリソースフォレストモデルで展開していない限りはないと言えます。

AAD ConnectでExchange属性が同期されない

ディレクトリ同期(AAD Sync含む)を利用する環境下において、Exchange Onlineで利用されるユーザーなどの情報は全てオンプレミスのActive Directoryから同期され、管理されます。

このため、アドレス帳非表示やふりがななど、メールボックスの動作を制御する一部の属性はオンプレミス側で設定し、同期する必要があります。オンプレミスにExchange Serverが無い場合は、その設定用にスキーマ拡張のみして属性を設定するというTIPSは比較的昔から存在していました。
20161210_01

こういった環境のユーザーがAAD Connectに移行すると、アドレス帳非表示の設定が消えるなどの影響が出る可能性があり、注意が必要です。

なぜかと言いますと、AAD Connectはマルチフォレスト(特にリソースフォレストモデルのExchange環境)のサポートを行うために、デフォルトの同期ルールが以前と変わっています。

具体的には、ユーザーの属性を取得する際に、Exchange関連の属性は[mailNickname]が存在するフォレストから取得するようになっています。

従来:
Azure Active Directory に同期した属性値のリスト

AAD Connect:
Azure AD Connect Sync: 既定の構成について

MailNicknameは、Exchangeにおける[Alias]として利用されている物であり、Exchange関連のオブジェクトであれば必須のパラメータとなっています。しかし、ADSIエディタなどでアドレス帳非表示を制御するmsExchHideFromAddressListsなどの属性を加える運用を行っている場合、mailNicknameには値が入っていないというケースが多くあります。

PowerShellから、Exchange属性であるmsExchHideFromAddressListsを同期しているルールを確認すると、[In from AD – User Exchange]というルールで同期されており、そのフィルタの条件はmailNicknameがNOTNULLということが分かります。
20161210_02

Get-ADSyncRule | ? {$_.AttributeFlowMappings -like "*msExchHideFromAddressLists*" -and $_.SourceObjectType -eq "user"} |  ft Name,Identifier
(Get-ADSyncRule -Identifier [上記で表示されたID]).ScopeFilter.ScopeConditionList

同様に、ルールエディタからも確認ができます。
20161210_03 20161210_04

※このルールはExchangeのスキーマ拡張がされていない環境では作成されません。また、マルチフォレスト、マルチドメイン環境では複数作成されます。

さて、では対応するためにどうしていけばいいかですが、アプローチとしては2つあります。

  1. [In from AD – User Exchange]のデフォルトルールを変更し、mailNicknameによる条件フィルタ自体を削除する
  2. [In from AD – User Exchange]をコピーして新たなルールを作成し、条件をmailNickname = NULLにする

いずれも、全ユーザーに対してExchange関連属性を設定するという意味では同じですが、今後ソフトウェア更新をした際にデフォルト設定が変わる可能性があるリスクを考えると2番の方がメンテナンス性は良いかと個人的には考えてます。(1で実装する場合も、実際には元の設定は無効化し、コピーしたルールに手を加えます)

手順ですが、Syncroniztion Rule Editorを管理者として起動し、[In from AD – User Exchange]のEditを選択する。この際、[YES:既存のルールのコピーを作成し、オリジナルのルールを無効化する][No:既存のルールの変更を続ける]の確認が表示されるので、[はい(Y)]を選択する。
20161210_05 20161210_09

Precedenceに既存と重複せず、元のルールより低い(数値の大きい)値を設定する。(ここでは200とした。)Scoping Filterの項目を開き、プルダウンのISNOTNULLをISNULLに変更する。
20161210_06 20161210_07

もう一度[In from AD – User Exchange]の[Edit]を選択し、今度は[いいえ(N)]を選択してオリジナルのルールを開く。[Disabled]のチェックを外して保存。
20161210_08

なお、既定の構成に手を加える場合は、以下の記事を一読されることをお勧め致します。 Azure AD Connect Sync: 既定の構成を変更するためのベスト プラクティス