2018/05/22

Windows 10: Windows 10 April 2018 Update (1803) を適用後 Outlook での IME が変

先日リリースされた Windows 10 April 2018 Update (1803) を適用した後、Outlook で本文を入力しているととても怪しい挙動をしています。
# Outlook 以外は今のところ現象に遭遇せず

 Windows 10 April 2018 Update (1803) + Office 365 ProPlus (1708.8431.2242)

ひらがな数文字を入力して漢字変換しようとすると、すでに1文字目のひらがなが確定されてしまい、2文字目以降で変換されたり、変換した漢字がずっと確定できなかったり。

最初はキーボードのハード的な問題かなと思っていたのですが、
常に起こるわけではなく、特にインターネット接続が弱い時(新幹線の中とか)に起こる感じです。
という事で、怪しむのは IME のクラウド予測変換機能。。。

お仕事に影響が出てきたので対処療法的に IME 予測変換機能を OFF にさせて頂きました。

画面右下のタスクトレイにある IME のアイコン ([あ] とか [A]) を右クリックして、プロパティをクリック

「Microsoft IME の設定」で [詳細設定] をクリック

「Microsoft IME の詳細設定」で、「予測入力」タブを開いて、「予測入力を使用する」のチェックを外す。
「予測入力サービス」の "クラウド候補" を外すのでも効果あるのかな?

予測変換の機能自体は便利なので OFF にはしたくないのですが、取り急ぎの対処。
時間があれば現象が出るパターンなど探してみようかと・・・。
「予測候補を表示するまでの文字数」のデフォルト 「1」文字ってのを増やすのも1つでしょうか。

Update されて治る事を願っています。

----------
2016/05/24 追記
既知の問題のようでMicrosoftでも調査中と Blog で発表されています。
やはり Outlook だけの問題なんですかね。早々に治る事を祈りましょう。

Windows 10 April 2018 Update (バージョン 1803) を適用後、Outlook での文字入力に問題が発生する
https://blogs.technet.microsoft.com/outlooksupportjp/2018/05/23/windows-10-april-2018/

2018/05/21

Office 365: Office 365 を登録されたデバイスのみ利用可能とする (その1)

最近、Office 365 の導入が進んで、かつ、Microsoft 365 の検討をされる方も多くなってきたようで、"Office 365" + "Enterprise Mobility + Security (EMS)" を使って Office 365 の利用のセキュリティ強化をしたいというご相談をちょいちょい聞くようになりました。

特に、EMS の中でも Azure AD Premium を使えば、これまで 3rd Party のサービスを使う必要があった 『"デバイス制御" (許可したデバイスからのみ利用させる) 』が Microsoft のサービスだけでできるかもしれない・・・という噂もあり、ちょいちょいと相談を受けている状況です。

それ、ADFS だよね?という点については一旦置いて置きます。
ADFSでも、WorkPlace Join など組み合わせてルールを書けば可能で、また、ユーザー証明書を組み合わせる事もできますが、極力クラウドベース(SaaS) でやりたい方向けです。


確かに、EMS でも出来なくはない・・・んですが、期待するものかどうかはという事で、この記事を書いてみます。
設定する箇所は Azure AD Premium の条件付きアクセス (↓ここ)になります。
[Office 365 管理コンソール] - [管理センター] - [Azure Active Directory] から「Azure Active Directory」の管理ページに移動して、[セキュリティ]の項目の中に「条件付きアクセス」のメニューがあります。

しかし、この機能を使って「許可したデバイスからだけ Office 365 を利用させる」制御の為には、いろいろとお膳立てが必要です。

そもそも、この機能を使用する為には、"制御したいデバイスを登録する" という事が必要になります。どこに登録するのかというと、この「条件付きアクセス」の機能が提供される "Azure AD" に対して登録を行う事になります。
よって、制御機能は Azure AD で行うので"認証"の付加機能として制御が利きます。
# 「ユーザーID + パスワード + 条件」という事

この条件として指定できる選択肢として、「デバイス」関連で言うと以下の2つが設定の中に存在しています。

 ・ハイブリッド Azure AD 参加済みのデバイスかどうか?
 ・準拠しているとマーク済みのデバイスかどうか?

"ハイブリッド Azure AD 参加" というのは、Windows 用のもので、社内の Active Directory にドメイン参加済みの Windows を、更に Azure AD に登録させる状態の事を言います。

"準拠しているとマーク済み"というのは、主に iOS や Android 用のもので(正確には Windows 10 も含む)、Microsoft Intune (など) の MDM にデバイスが登録(管理下)がされており、更に、その MDM によって配布する会社の定めたポリシー(OSのバージョンや非脱獄)に問題ない(準拠している)とチェックが完了している状態の事を言います。

※ カッコ補足の多さがこの機能のややこしさを物語る。。。

これらで、「会社の AD にドメイン参加していない Windows からはアクセスさせない」シナリオや、「会社の MDM に登録しない or 安全でない使い方してるモバイル端末からはアクセスさせない」シナリオに対応する事ができます。

では、どのようにデバイスを登録するか?という方法について、

モバイルデバイス (iOS/Andorid) については解り易く、要はアクセスする端末を会社の MDM (Intune) の管理下に置きなさいという事になります。(よって、私物の端末についてはちょっと勇気が要る)
登録の詳しい方法などは、Microsoft Intune の docs などをご覧ください。

会社のリソースへのアクセスを設定する
https://docs.microsoft.com/ja-jp/intune-user-help/enroll-your-device-in-intune-ios
Intune に Android デバイスを登録する
https://docs.microsoft.com/ja-jp/intune-user-help/enroll-your-device-in-intune-android
Intune デバイスのコンプライアンス対応ポリシーの監視
https://docs.microsoft.com/ja-jp/intune/compliance-policy-monitor

Windows についてはちょっとややこしい。。。

"ハイブリッド Azure AD 参加" をさせる為には、
まず、Windows が、"Windows 10"(Version 1607 以降) か "Windows 8.1 or 7" によって異なります。
また、"Azure AD Connect" による 社内 AD と Azure AD との同期は必須になります。
更に、"Windows 8.1 or 7" の場合、"ADFS" もしくは "シームレス SSO" (Azure AD Connect のサブセット機能) が必要になります。

構成方法については、下記の通り Microsoft さん純正の説明ページがあります。

ハイブリッド Azure AD 参加済みデバイス
https://docs.microsoft.com/ja-jp/azure/active-directory/device-management-introduction#hybrid-azure-ad-joined-devices
ハイブリッド Azure Active Directory 参加済みデバイスの構成方法
https://docs.microsoft.com/ja-jp/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup

上記サイトが詳しく書いてあるので、必要か分かりませんが自分用メモも兼ねてザックリ構成メモを書いておきます。
@ ADFS 環境ではなく シームレス SSO 環境を前提

まずは、Azure AD Connect を構成し、必要に応じて(Windows 8.1 or 7 がある場合)、シームレス SSO を構成します。なお、Azure AD に登録するデバイスについても同期させる必要があるため、OU などで同期フィルタリングをしている場合は、AD のコンピューターオブジェクトが含まれる OU も同期する必要があります。

ネットワーク的に、プロキシなどを利用している場合、Windows 10 のデバイス登録の為には、WinHTTP の通信が必要になるので、WPAD によるプロキシの構成が必要な点も注意が必要です。

あとは、社内 AD にデバイス登録を行う為の SCP (サービス接続ポイント) の登録が必要です。
Azure AD Connect サーバー上に "Enterprise Admin" 権限を有するユーザーでログインして、以下の PowerShell を実行して登録します。
Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1";
$aadAdminCred = Get-Credential;
Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred;
ただし、上記のコマンドの為には、以下の準備が必要です。

・"Active Directory PowerShell モジュール" と "AD DS ツール"
  ⇒ サーバーの役割と機能の追加から、[機能]-[リモートサーバー管理ツール]- [役割管理ツール] の配下
・PowerShell 5.0 以降 (次の "Install-Module" を実行する為)
・MSOnline PowerShell module version 1.1.166.0
  ⇒ PowerShell でコマンド実行
    [ Install-Module -Name MSOnline -RequiredVersion 1.1.166.0 ]

ちなみに、表示される認証画面で入力するユーザーは、Azure AD の全体管理者権限を有するユーザーで、コマンド内の "-AdConnectorAccount" で指定するユーザーは、Azure AD Connect のインストール時に指定した 社内 Active Directory へ接続する為のアカウントを指定するとの事。(不明な場合は、Azure AD Connect の構成画面で確認できます)

その他、AD のグループポリシーで 対象のユーザー/コンピューターに対して、IE のローカル イントラネット ゾーンに以下の URL を追加します。
https://device.login.microsoftonline.com

上記で前準備が完了なので、あとは Azure AD へのデバイス登録を行います。

<Windows 10 の場合>
デバイスを登録したいコンピューターが所属する OU を作成して、グループポリシーを作成した上で紐づけます。
作成したグループポリシーを編集して、以下の内容を構成します。

※ Windows 10 のポリシーなので Windows 10 Version 1607 以降用の GPO テンプレートが必要です。

[コンピューターの構成] > [ポリシー] > [管理用テンプレート] > [Windows コンポーネント] > [デバイスの登録] で、
[ドメインに参加しているコンピューターをデバイスとして登録する] を [有効] にします。

デバイス側に GPO が適用された後、次回ドメインユーザーで Windows 10 へサインイン時に登録タスクが動作して、Azure AD へデバイスが登録されます。

<Windows 8.1 or 7 の場合>
Windows 8.1 or 7 の場合は、リリース時点で ハイブリッド AD 参加の仕組みが無い為、Azure AD へ参加する機能を追加してあげる必要があります。

Microsoft Workplace Join for non-Windows 10 computers
https://www.microsoft.com/en-us/download/details.aspx?id=53554

よって、このモジュールがインストールされているかどうか?が登録済みデバイスであるかどうか?の分かれ目になります。(+ 社内 AD へのドメイン参加は必要です)

なお、Windows 8.1 or 7 の場合、登録をさせたくない場合は、この機能のインストールを防ぐ (実行させない) ようにする仕組みが必要となります。


という事で、上記の通り、EMS を使ったデバイス制御は 3rd Party のサービスであるような「デバイスの利用申請があって、許可 or 拒否 を管理者が制御する」といったイメージではない点に注意が必要なのかなと思います。

後は、Azure AD の条件付きアクセスでポリシーを作るのですが、長くなったので、トラブルシューティング方法と絡めて次回。。。


2018/02/16

Office 365: PowerShell から CSOM で SharePoint Online のリミット (429) を回避して操作する

最近、CSOM を使って SharePoint Online へ接続する際に、SharePoint Online 側の制限が厳しくなったのか、Limit に引っかかり 429 の HTTP Response エラーとなる確率が高くなってきたようです。

回避方法としては、UserAgent を付けるのと、リトライを行う事とのこと。
あくまでも 100% 回避できる訳ではない事に注意が必要です。

SharePoint Online で調整またはブロックを回避する
https://docs.microsoft.com/ja-jp/sharepoint/dev/general-development/how-to-avoid-getting-throttled-or-blocked-in-sharepoint-online

C#版のサンプルコードは Microsoft から出ている(一部Bugってるが・・・)ものの、両方の対策に対応した PowerShell 版のサンプルが Microsoft から出ていないので、作ったものを自分の備忘を兼ねて書いておきます。

ちなみに、リトライを行う PowerShell のサンプルは Microsoft のサポートの森さんが記載されているので、リトライを行う部分は 森さんのコードをそのまま拝借しています。

PowerShell サンプル : SharePoint Online HTTP 調整 (応答コード : 429) 対策の増分バックオフ リトライ
https://blogs.technet.microsoft.com/sharepoint_support/2016/10/08/powershell-csom-sample-code-for-spo-http-429-incremental-backoff-retry/

以下、PowerShell の Sample コード (DLLのURLは適宜変更してください)
指定したサイト($siteUrl)内のリスト一覧を取得します。
#==========================================

Add-Type -Path "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.Client.dll"
Add-Type -Path "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.Client.Runtime.dll"

function ExecuteQueryWithIncrementalRetry($retryCount, $delay)
{
  $retryAttempts = 0;
  $backoffInterval = $delay;
  if ($retryCount -le 0)
  {
    throw "Provide a retry count greater than zero."
  }
  if ($delay -le 0)
  {
    throw "Provide a delay greater than zero."
  }
  while ($retryAttempts -lt $retryCount)
  {
    try
    {
      $script:context.ExecuteQuery();
      return;
    }
    catch [System.Net.WebException]
    {
      $response = $_.Exception.Response
      if ($response -ne $null -and $response.StatusCode -eq 429)
      {
        Write-Host ("CSOM request exceeded usage limits. Sleeping for {0} seconds before retrying." -F ($backoffInterval/1000))
        #Add delay.
        Start-Sleep -m $backoffInterval
        #Add to retry count and increase delay.
        $retryAttempts++;
        $backoffInterval = $backoffInterval * 2;
      }
      else
      {
        $retryAttempts++;
        throw;
      }
    }
  }
  throw "Maximum retry attempts {0}, have been attempted." -F $retryCount;
}

function AddUserAgent()
{
param([Parameter(Mandatory=$true)][object]$Context)

    $Assemblies = (
        "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.Client.dll", `
        "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.Client.Runtime.dll"
    )

    $CSharpSource=@"
using System;
using Microsoft.SharePoint.Client;

public static class CSOMContexChanger
{
public static void CSOMAddUserAgent(ClientContext context)
{
            context.ExecutingWebRequest += delegate (object sender, WebRequestEventArgs e)
            {
                e.WebRequestExecutor.WebRequest.UserAgent = "NONISV|Contoso|PowerShellScript/1.0";
            };
}
}
"@

Add-Type -TypeDefinition $CSharpSource -ReferencedAssemblies $Assemblies -Language CSharp
    [CSOMContexChanger]::CSOMAddUserAgent($Context);
}

# Set Site URL
$siteUrl = "https://<TenantName>.sharepoint.com/sites/<SiteName>/"
# Set Credential
$Credentials = Get-Credential

$script:context = New-Object Microsoft.SharePoint.Client.ClientContext($siteUrl)
$script:context.Credentials = New-Object Microsoft.SharePoint.Client.SharePointOnlineCredentials($Credentials.UserName,$Credentials.Password)

# Call UserAgent to SPContext Method
AddUserAgent $script:context

$lists = $script:context.Web.Lists
$script:context.Load($lists)

# Call ExecuteQuery with Retry Method
ExecuteQueryWithIncrementalRetry -retryCount 5 -delay 30000

$lists | ForEach-Object{ "Title: {0}" -f $_.Title }

#==========================================

2016/10/17

Windows 2016: 仮想マシンの自動アクティベーション

かなり久々の更新です。

Windows Server 2016 がリリースされたので久々に備忘までに更新しておきます。

Windows Server 2016 DataCenter Edition がインストールされたホスト OS (Hyper-V) の場合、仮想OSE (仮想マシン) は無制限に作成する事が可能です。

Windows Server 2016 DataCenter Edition では、その無制限に作成可能な仮想マシンのアクティベーションを簡略化する Automatic Virtual Machine Activation (AVMA) という機能が Windows Server 2012 R2 の頃から追加されています。

要は、ホストOS のアクティベーションが完了しているなら、その上で動く仮想マシンのアクティベーションは自動でOKとなる(Microsoftと通信なし)という事みたいです。

検証環境やクローズの環境を仮想マシンで作成する場合、インターネット接続があるとは限らないですし、毎回、同じキーでアクティベーションしていたら、アクティベーションの上限回数も気にしないといけないですから、便利です。

ホストとゲストの使用条件は以下の通り

仮想ホスト :
Windows Server 2012 R2 DataCenter Edition
Windows Server 2016 DataCenter Edition
仮想ゲスト :
Windows Server 2012 R2 DataCenter , Standard , Essentials
Windows Server 2016 DataCenter , Standard , Essentials


やり方としては、仮想ゲストのプロダクトキーの入れ替えも必要です。
GUIから変更も可能ですし、"slmgr /ipk <プロダクトキー>" で行います。

設定するプロダクトキーはこちら。仮想ゲストで使用する Edition によって異なります。

2012 R2AVMA Key
DatacenterY4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
StandardDBGBW-NPF86-BJVTX-K3WKJ-MTB6V
EssentialsK2XGM-NMBT3-2R6Q8-WF2FK-P36R2

2016AVMA Key
DatacenterTMJ3Y-NTRTM-FJYXT-T22BY-CWG3J
StandardC3RCX-M6NRP-6CXC9-TW2F2-4RHYD
EssentialsB4YNW-62DX9-W8V6M-82649-MHBKQ

今のところ、英語の情報しかないみたいですが、詳しくはこちらをご覧ください。
http://technet.microsoft.com/en-us/library/dn303421.aspx

2015/06/28

Office 365: Microsoft Intune が有効なテナントでは Office 365 MDM が使えない

Office 365 MDM (モバイルデバイス管理) 機能が Office 365 の標準機能として提供されたとの事で、早速、自分のテナントでも試してみたいと試みました。

Office 365 用のモバイル デバイス管理の概要

Office 365 管理画面の左のメニューに「モバイル デバイス」というものが増えています。
どうやら、ここから構成すればOK! という事なので早速クリック!

が、、、しかし!

「セットアップする必要はありません」との事。。。

よくよく読むと、すでに Microsoft Intune を同じサブスクリプションで有効化してしまっている為、Office 365 の MDM は必要ないだろう。。。という事でした。

確かに、Microsoft Intune でもろもろ iPad などの制御が可能なので必要はないのですが・・・・

という事で、断念しました。

また、別の試用版環境などでも構築して機能を見てみたいと思います。

=========
詳しい方に教えていただきました。

既に Microsoft Intune を使い始めてる人が、どうしても Office 365 MDM を使いたい場合、サポートへ問い合わせをしてお願いをすれば使えるようになるそうです。

ただし、既存の Microsoft Intune の情報が消えたり、いろいろと厄介な事になるとの事なので、そんな勇気はなく、諦めました x2。


2015/06/26

Azure: Azure AD Sync から Azure AD Connect にアップグレードしてみた

昨日、GA した Azure AD Connect ですが、これまでのディレクトリ同期ツール や Azure AD Sync (AADSync) に置き換わるものとされています。

ディレクトリ同期ツール や AADSync から簡単にアップグレード (移行?) できるとの事なので、早速、AADSync からインプレースで置き換えてみました。

元の環境は、Windows Server 2012 R2 上にインストールした AADSync で、2つの AD フォレスト と Azure AD (Office 365) を繋いでます。

■ アップグレードしてみる

早速、Azure AD Connect をダウンロード。まだ英語版しかないです。日本語版もでるのかな?
ダウンロードした MSI ファイルを実行します。

ウィザードが立ち上がり、既に同期サービスがインストールされてるよ!っと判断して、Upgrade モードになっています。
「I agree to the license terms and privacy notice.」にチェックを入れて、[Continue] を押します。

Azure AD Sync から Azure AD Connect にアップグレードする間、同期は止まるよとのこと。
[Upgrade] を押します。

後は、待つだけ。簡単楽ちんです。各種設定情報も引き継いでくれるみたいです。

次に、Azure AD の認証情報を入力しろとの事なので、Azure AD の管理者アカウント(xxx@contoso.onmicrosoft.com) を入力。

「Ready to configure」と表示されて引き継ぎ準備完了との事なので、「Start the synchronization process as soon as the configuration completes.」にチェックを入れて、「Upgrade」を押します。

待つだけ。

完了したメッセージに変わったら 「Exit」 で終了。

ちなみに、インストール後の「プログラムと機能」はこんな感じになりました。

これで一通りのアップグレードは完了です。
大きな変更はなさそうなので非常に簡単です。

ディレクトリ同期ツールからのアップグレード方法についても詳しく公開されてますね。
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-aadconnect-dirsync-upgrade-get-started/
新しいサーバーを立てて、構成情報を Export して Import することも可能との事。

■ 構成してみる

アップグレードが完了すると、デスクトップ上に "Azure AD Connect" というショートカットが出現します。
構成ウィザードのショートカットです。


起動してみるとウィザードが立ち上がってきます。

Additional tasks として、3つの選択肢が出てきます。

  •  View current configuration (現在の構成を参照)
  •  Customize synchronization options (同期オプションの変更)
  •  Configure staging mode (ステージングモードの構成)


 ・ View current configuration (現在の構成を参照)

見るだけです。


・Customize synchronization options (同期オプションの変更)

構成した同期の設定を変更したり追加したりできます。

AADSync の時から引き続きオンプレADのマルチフォレストなので、必要に応じてここで追加します。
今現在は、"DIRECTORY TYPE" が "Active Directory" しか選べませんが、いずれ他のディレクトリもサポートされる予定との事。

「Optional feature」に Preview の各種機能が増えてます(?)よね?
"User writeback","Group writeback","Device writeback","Directory extension attribute sync" が選択 Preview 機能として選択できるようになってます。これらの機能はまたいづれ試したいと思います。

どのアプリケーションを対象にするのかも変更ないです。
必要に応じて「I want to restrict the list of applications" にチェックを入れて制限します。

同期する属性の選択です。ここでも必要に応じて "I want to further limit the attributes exported to Azure AD." を選択した上で、不要なもののチェックを外します。

後は、"Start the synchronization process as soon as the configuration completes." にチェックを入れて、「Install」を押せば構成されます。

終わったらこんな感じ。

ちなみに、こんなエラーが出た場合は、過去に倣って、事前に構成済みのタスクをタスクスケジューラーから無効にしておく必要があります。

[コンパネ]-[管理ツール]-[タスク スケジューラ] で "Azure AD Sync Scheduler" を無効に設定してください。

・Configure staging mode (ステージングモードの構成)

新しくついた機能ですね。ちょっと名前的に「検証環境?」というイメージになりますが、どうやら、ディザスタリカバリー(DR)を想定した機能のようです。

プライマリーで動作する Azure AD Connect の同期サービスが長期で停止した際、あらかじめ Staging mode を有効にした別拠点のセカンダリーの Azure AD Connect の同期サービス を用意しておけば、Staging mode を無効化するだけでプライマリーとして動作するようになるとの事。

実際設定検証はやってないのですが、設定画面の画面ショットだけ・・・

 セカンダリーのサーバー側では、この「Enable staging mode」にチェックを入れれば良いという事ですね。

「Install」を押せば Staging mode が有効になります。

■ 補足

例によって Azure AD Connect は Forefront Identity Manager ベースで動いています。
よって、FIM のコンソールも見ることができます。

Program Files\Microsoft Azure AD Sync\UIShell にあります。

バージョンを確認するとちゃんと "Azure AD Connect Service"となっているのが確認できます。


同期属性の選択部分に増えた項目が並んでます。

 AADSync から増えた "SyncRulesEditor" も同じフォルダに入ってます。

同期のフィルタなどルールの変更をこのエディターからでも行うことが可能です。


また時間を見つけて Preview 機能のあたりについても見てみたいと思います。

2015/06/25

Azure: Azure Active Directory Connect が GA

以前より、Office 365 の AD 同期などでおなじみの "ディレクトリ同期ツール" "Azure AD Sync" などの後継ツールを含むサービスとして Preview が公開されていた Azure Active Directory Connect  が GA したとのこと。
Integrating your on-premises identities with Azure Active Directory

Azure AD Connect 自体は、同期サービス全体を指す感じの位置づけですね。

Connectツールのダウンロードはこちら
Microsoft Azure Active Directory Connect 

今のところ、まだ英語版のみのようですね。


ついでに、Azure AD Premium が必要なようですが、Azure Active Directory Connect Health も GA とのこと。


追々、既存の Azure AD Sync ツール を置き換えていきたいとおもいます。

2015/05/08

Exchange: Exchange がついに Azure 上でサポート!

あまりに Blog を放置しすぎてた・・・。

軽くリハビリから。

これまで AWS ではサポート(?) されていた Exchange Server ですが、ようやく Azure 上での稼働もサポートされるようです。

Exchange 2013 virtualization
https://technet.microsoft.com/en-us/library/jj619301(v=exchg.150).aspx

Deployment on Microsoft Azure virtual machines is supported if all storage volumes used for Exchange databases and database transaction logs (including transport databases) are configured for Azure Premium Storage.

Exchange の Database と トランザクションログ (トランスポートDBも含む) を Azure Premium Storage 上に配置する事が条件になります。

やはり、ストレージの I/O がネックだったようですね。

とは言え、Exchange の配置場所の選択肢が増えてよかったです。


まぁ、ただ Public Cloud は 「停止する事を前提に設計せよ!」 との鉄則があるので、どういったメールボックスを持っていくのか?何なら、Exchange Online で十分では?という声もありますが・・・w

ハイブリッド目的の検証環境構築などには活躍しそうですね。

2015/01/16

Azure: 仮想マシンに接続可能なディスク本数

Microsoft Azure の仮想マシンに対して接続可能なディスク数を纏めておきます。
個人的によく調べるので・・・

ちなみに、Azure のディスクはMAX 1TB です。
ですので、1TB を超える容量が仮想マシンに必要な場合は、必要に応じて仮想マシンのサイズを大きくして、1TB のディスクを数本刺した上で OS 側でソフトウェアRAIDを組むなりする必要があります。

あと、話は脱線しますが、Azure のディスクへの課金は "設定している容量" ではなく "使われている容量" が対象となります。

Aシリーズ、Dシリーズ、Gシリーズ について纏めます。

※ 基本的には コア数 x 2 が最大 Disk 本数ですね。

■ 基本プラン

サイズ CPU
コア
メモリ ディスクサイズ -
仮想マシン
最大データ ディスク数
(各ディスク1TB)
A0 1 768 MB OS = 127 GB
一時ディスク = 20 GB
1
A1 1 1.75 GB OS = 127 GB
一時ディスク = 40 GB
2
A2 2 3.5 GB OS = 127 GB
一時ディスク = 60 GB
4
A3 4 7 GB OS = 127 GB
一時ディスク = 120 GB
8
A4 8 14 GB OS = 127 GB
一時ディスク = 240 GB
16

■ 標準プラン

サイズ CPU
コア
メモリ ディスクサイズ -
仮想マシン
最大データ ディスク数
(各ディスク1TB)
A0 1 768 MB OS = 127 GB
一時ディスク = 20 GB
1
A1 1 1.75 GB OS = 127 GB
一時ディスク = 40 GB
2
A2 2 3.5 GB OS = 127 GB
一時ディスク = 60 GB
4
A3 4 7 GB OS = 127 GB
一時ディスク = 120 GB
8
A4 8 14 GB OS = 127 GB
一時ディスク = 240 GB
16
A5 2 14 GB OS = 127 GB
一時ディスク = 135 GB
4
A6 4 28 GB OS = 127 GB
一時ディスク = 285 GB
8
A7 8 56 GB OS = 127 GB
一時ディスク = 605 GB
16
A8 8 56 GB OS = 127 GB
一時ディスク = 382 GB
16
A9 16 112 GB OS = 127 GB
一時ディスク = 382 GB
16
D1 1 3.5 GB OS = 127 GB
一時ディスク(SSD) = 50 GB
2
D2 2 7 GB OS = 127 GB
一時ディスク(SSD) = 100 GB
4
D3 4 14 GB OS = 127 GB
一時ディスク(SSD) = 200 GB
8
D4 8 28 GB OS = 127 GB
一時ディスク(SSD) = 400 GB
16
D11 2 14 GB OS = 127 GB
一時ディスク(SSD) = 100 GB
4
D12 4 28 GB OS = 127 GB
一時ディスク(SSD) = 200 GB
8
D13 8 56 GB OS = 127 GB
一時ディスク(SSD) = 400 GB
16
D14 16 112 GB OS = 127 GB
一時ディスク(SSD) = 800 GB
32
G1 2 28 GB OS = 127 GB
一時ディスク(SSD) = 412 GB
4
G2 4 56 GB OS = 127 GB
一時ディスク(SSD) = 824 GB
8
G3 8 112 GB OS = 127 GB
一時ディスク(SSD) = 1,649 GB
16
G4 16 224 GB OS = 127 GB
一時ディスク(SSD) = 3,298 GB
32
G5 32 448 GB OS = 127 GB
一時ディスク(SSD) = 6,596 GB
64

※ 投稿時点では G Series は West U.S. region でのみ利用可能です。
※ OS領域やデータ領域で SSD を利用するには 投稿時点で Preview 中の Premium Storage が必要です。

<参考>
Azure の仮想マシンおよびクラウド サービスのサイズ
http://msdn.microsoft.com/ja-jp/library/azure/dn197896.aspx

General Availability: G-Series for Virtual Machines
http://azure.microsoft.com/en-us/updates/general-availability-g-series-for-virtual-machines/

2015/01/13

Office 365: 各種サービスへのPowerShellでの管理接続

今更ながら纏めてみた。


※ 全体を通じた必須モジュール

PowerShell 3.0 以上 (Windows 7 以下の場合)
http://www.microsoft.com/en-us/download/details.aspx?id=34595

IT プロフェッショナル 用 Microsoft Online Services サインイン アシスタント RTW
http://go.microsoft.com/fwlink/p/?LinkId=286152

[追記]
Windows PowerShell スクリプトの実行権限の変更が必要な場合があります。
変更する為には、PowerShell を [管理者として実行] で起動し、以下のコマンドを実行。
Set-ExecutionPolicy RemoteSigned
※ "RemoteSigned"の部分がポリシーの内容になるので適宜最適なものに変更してください。
  https://technet.microsoft.com/ja-jp/library/ee176961.aspx

■ Azure Active Directory

◇ 必要追加モジュール

Windows PowerShell 用 Azure Active Directory モジュール (64 ビット バージョン)
http://go.microsoft.com/fwlink/p/?linkid=236297

◇ PowerShell コマンド
Connect-MsolService

■ Exchange Online

◇ 必要追加モジュール

なし

◇ PowerShell コマンド
$UserCredential = Get-Credential $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection Import-PSSession $Session

■ Skype for Business Online (Lync Online)

◇ 必要追加モジュール

Skype for Business Online, Windows PowerShell Module
https://www.microsoft.com/ja-JP/download/details.aspx?id=39366

◇ PowerShell コマンド
Import-Module SkypeOnlineConnector $credential = Get-Credential $session = New-CsOnlineSession -Credential $credential Import-PSSession $session

■ SharePoint Online

◇ 必要追加モジュール

SharePoint Online Management Shell
http://www.microsoft.com/ja-jp/download/details.aspx?id=35588
# 2015/1/13 抜けていた為に追記 - 大鷲様ご指摘ありがとうございました!

◇ PowerShell コマンド
Connect-SPOService -Url https://contoso-admin.sharepoint.com -credential admin@contoso.com