That depends

Office 365: Office 365 に許可されたデバイスでのみ利用させる方法

2019-08-08T18:30:00.000+09:00

Office 365 に許可されたデバイスでのみ利用させる方法、デバイス認証というものをマイクロソフトが提供する機能だけで実現するためにはどうすれば良いか、調べてみたらいろいろとややこしかったので自分なりにメモを残しておこうと思います。

※ 脳内整理のメモ書きなのでご了承ください。
※ 間違った認識の部分もあるかもしれません、ご了承ください。
※ クライアント側もADALに対応したアプリを使用している事を前提としてます。

ライセンス的な結論としては、今後このパターンで Azure AD Premium は必須ですね。
iOS/Android端末まで考慮すると、Intune も必要になりそうです。(そうなるとEMSですか・・・)

基本的には Active Directory Federation Service (ADFS) を念頭において考えてます。
その上で、ADFSを構築しないパターンも考えてみました。

登録されたデバイスのみ許可をするという事なので、やはり、「デバイスをどうやって登録するのか？」という点と、「登録したデバイス情報をどこに保管するか？」という点になるかと思います。

また、ちなみに制御する場所としては、
・ADFS で、認証アクセスしてきた際に登録済みデバイスかどうか制御する
・Azure AD で、条件付きアクセスで登録済みデバイスかどうか制御する

ADFSで制御するためには、Active Directory(AD)でデバイスを管理する必要があります。

考慮ポイントを纏めてみました。

■Windows端末の場合

【ADFSでデバイス認証する場合】
・ADFS2012R2にはデバイス登録する仕組み(DRS)が提供されていたがADFS2016ではなくなってる(ノンサポート)
・Windows 10 は ADFS2012R2のデバイス認証には対応していない。
・Azure ADにもデバイスを登録する仕組みがあり、Windows 10 や iOS/Android にのみ対応しており、Azure AD へデバイス登録が可能
　⇒ Azure AD に登録されたデバイス情報は Azure AD Connect (同期サーバー)経由でADに“ライトバック”(デバイスの書き戻し) できる
　　※ ライトバックを使うには Azure AD Premium ライセンスが必要。
　　⇒ AD に Windows 10 をデバイス登録するためには、Azure AD へデバイス登録した情報をライトバックするしかない

【Azure ADの条件付きアクセスでデバイス認証する場合】
・オンプレADのドメインに参加済みのクライアントOSを、Azure ADにもデバイス登録する”ハイブリッドAD参加”を構成
　⇒ "ハイブリッドAD参加"する事で Azure AD Premium で提供される「条件付きアクセス」の「デバイス認証」機能の ”ハイブリッドAD参加で登録済みデバイス” という条件用として使える

　※　“ハイブリッドAD参加” の利用条件として “Windows 統合認証” があり、この条件を満たすためには以下のいずれかの構成を組む必要がある
　　　・社内にADFS を構成する
　　　・社内に Azure AD Connectのオプションである “シームレスSSO” を構成する
　※　“ハイブリッドAD参加” の利用条件として Windows 7 以前の端末の場合、追加モジュール(.msi)を端末に配る必要がある

■iOS/Android端末の場合

【ADFSでデバイス認証する場合】
・ADFS2012にはデバイス登録する仕組み(DRS)が提供されていたがADFS2016ではなくなってる(ノンサポート)
・ADFS(2012まで) のデバイス登録する仕組み(DRS)に対して iOS/Android からWorkplace Joinを使ってADへのデバイス登録
・Azure ADにもデバイスを登録する仕組みがあり、Windows 10 や iOS/Android にのみ対応しており、Azure AD へデバイス登録が可能
　⇒ Azure AD に登録されたデバイス情報は Azure AD Connect (同期サーバー)経由でADに“ライトバック”(デバイスの書き戻し) できる
　　※ ライトバックを使うには Azure AD Premium ライセンスが必要。

【Azure ADの条件付きアクセスでデバイス認証する場合】
・Azure AD Premium の「条件付きアクセス」で使える「デバイス認証」の条件が、「ハイブリッドAD参加」か「準拠するデバイス」という２つの条件
　　⇒ 「ハイブリッドAD参加」は Windows 端末の為のもの (オンプレADへのドメイン参加が必要)
　　⇒ iOS/Androidは「準拠するデバイス」の方を使うしかない
　　　⇒ 「準拠するデバイス」の「準拠」の証明を得るためには、Intune の管理下にデバイスを置く必要がある
　　　　⇒ 「Azure AD Premium」の「条件付きアクセス」でデバイス認証するためには、iOS/Android用にIntuneの契約も必要

それぞれの具体的な方法(ADFSのDRSの構成、WorkPlaceJoin、ハイブリッドAD参加など)は Microsoft の各種情報を参照頂ければと思います。

↓本Blog の内容をきれいに纏めてある記事がありました。。。

デバイスベースのアクセス制御

https://blogs.technet.microsoft.com/jpazureid/2018/01/25/device_access/

その他、下記のサイトも参考にさせて頂きました。

オンプレミスのデバイスベースの条件付きアクセスを計画する

https://docs.microsoft.com/ja-jp/windows-server/identity/ad-fs/deployment/plan-device-based-conditional-access-on-premises

[Always on the clock] Windows Server 2012 R2を使ってiOSだけがOffice365にアクセスできるようにする

http://azuread.net/2013/09/17/windows-server-2012-r2%e3%82%92%e4%bd%bf%e3%81%a3%e3%81%a6ios%e3%81%a0%e3%81%91%e3%81%8coffice365%e3%81%ab%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e3%81%a7%e3%81%8d%e3%82%8b%e3%82%88%e3%81%86%e3%81%ab-2/

Office 365: Skype for Business Online が提供終了 (2021/7/31)

2019-07-31T14:42:00.002+09:00

※ 久しぶりの投稿がこれかという感じですが・・・

Office 365 のスイート製品で提供されてきた Skype for Business Online が Microsoft Teams への機能移行が完了してきた事もあり、ついに、提供終了される日が 2021年7月31日(米国時間だと思います) だと Microsoft からアナウンスされました。

Office 365 は重要なサービス更新は 1年前にはアナウンスされるというお約束だったかと思いますので、この 2年前に発表というのはよほどのインパクトを考慮してのことかなと思います。

ここまで新規テナントについては Skype for Business Online は含まれず、Microsoft Teams になったり、250ユーザー以下などの条件に合致するテナントは、積極的に Microsoft Teams への移行を案内されてきたりしましたが、いよいよ終了という感じですね。

既存の Skype for Business Server (オンプレミス版) や Skype (無償版,コンシューマー版) については、この Skype for Business Online の提供終了の影響はないとの事。

これで、いよいよ本格的に Skype for Business Online から Teams への移行を検討する必要がでてきました。特に、Voice連携している場合は早めに動く必要がありそうです。(その影響もあり2年前発表なんでしょう)

Microsoft Teams は、Skype for Business Online のようなシンプルなチャット/Web会議ツールではなく、チームという考え方(コミュニケーションの基盤)がベースにあり、その上でのチャットやWeb会議機能が存在する事もあり (またチーム機能はオフにできない。チャット機能はオフにできるけど・・・)、少し移行するにあたり考慮点が増えるという部分があります。

Teams は使っていて間違いなく Microsoft が力を入れている製品で、ものすごい勢いで機能強化がおこなれており、もしかしたら、今後、Microsoft Teams もマルチウィンドウ対応やチャット機能切り出しなどが増える可能性もあるかもしれませんが、そういった進化の速さについてもある意味ついていく必要もあります。

移行・導入には少し高い壁のありそうな Microsoft Teams ですが、「うまく活用できれば働き方も変えれるよね」という方も多いですし、実現されている会社さんも聞きますので、うまく会社の文化と融合させながら活用していきたいですね。

Office 365 にとってもインパクトの大きな話題だなと思ったので久々に投稿してみました。

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

2018-05-22T08:21:00.000+09:00

<2018/07/26 Update>
修正プログラムがリリースされたとの事！

先日リリースされた 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」文字ってのを増やすのも１つでしょうか。

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

----------
2018/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/07/26 追記
ようやく修正プログラムがリリースされたようです！

対処方法 (2018/7/25 update)
Windows 10 の修正プログラム KB4340917 (OS Build 17134.191) を適用することで、本現象が回避いたします。

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

不憫な中でなかなか待ちましたよ。。。
問題発覚して修正プログラム取り下げとかない事を祈ります。

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

2018-02-16T22:43:00.000+09:00

最近、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 }

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

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

2016-10-17T15:23:00.000+09:00

かなり久々の更新です。

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 R2	AVMA Key
Datacenter	Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
Standard	DBGBW-NPF86-BJVTX-K3WKJ-MTB6V
Essentials	K2XGM-NMBT3-2R6Q8-WF2FK-P36R2

2016	AVMA Key
Datacenter	TMJ3Y-NTRTM-FJYXT-T22BY-CWG3J
Standard	C3RCX-M6NRP-6CXC9-TW2F2-4RHYD
Essentials	B4YNW-62DX9-W8V6M-82649-MHBKQ

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

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

2015-06-28T17:18:00.000+09:00

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

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

https://technet.microsoft.com/ja-jp/library/ms.o365.cc.devicepolicy.aspx

Office 365 管理画面の左のメニューに「モバイルデバイス」というものが増えています。

どうやら、ここから構成すればOK! という事なので早速クリック！

が、、、しかし！

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

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

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

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

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

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

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

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

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

2015-06-26T21:09:00.000+09:00

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

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

元の環境は、Windows Server 2012 R2 上にインストールした AADSync で、２つの 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 機能のあたりについても見てみたいと思います。

Azure: Azure Active Directory Connect が GA

2015-06-25T20:32:00.000+09:00

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

Azure AD Connect & Connect Health is now GA!
http://blogs.technet.com/b/ad/archive/2015/06/24/azure-ad-connect-amp-connect-health-is-now-ga.aspx

Integrating your on-premises identities with Azure Active Directory

https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect/

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

Connectツールのダウンロードはこちら

Microsoft Azure Active Directory Connect

http://www.microsoft.com/en-us/download/details.aspx?id=47594

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

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

https://msdn.microsoft.com/library/azure/dn906722.aspx

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

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

2015-05-08T18:01:00.000+09:00

あまりに 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 で十分では？という声もありますが・・・ｗ

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

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

2015-01-16T22:10:00.000+09:00

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/

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

2015-01-13T21:20:00.000+09:00

今更ながら纏めてみた。

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

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

AWS: AWS をバーチャルクレジットカードで使えなかった・・・

2014-06-10T06:39:00.000+09:00

ちょっとした情報まで。。。

ひょんなきっかけで Amazon Web Services (AWS) をお試しする機会があり、無償のアカウントを契約するにあたりクレジットカードが必要との事でしたので、セキュリティの事も考えバーチャルクレジットカードを利用してみましたが、AWS でバーチャルクレジットカードは使えませんでした。

選択したバーチャルクレジットカードは e-さいふ (三菱UFJニコス)

カードを発行してAWSへ登録するところまではうまくいったのですが、審査が通らなかったようです。

書かれている事はある程度確認したんですけどねぇ～。。。

結局、タイムオーバーで素直に通常のクレジットカードで審査通しました。

AWS は何かにつけて英語なので英語弱者にはツラいところもありますね。。。

Office 365: Office 365 テナントに設定した ADFS サーバー (URL) を変更する

2014-05-02T18:42:00.007+09:00

大した話ではないのですが、Office 365 の検証をしている際にあまり情報がなかったので、備忘録までに記載しておきます。

既に Office 365 を SSO として設定し、既存の ADFS サーバーとフェデレーションの設定を行っている状況で、別に建てた ADFS サーバーへ移行する際の手順です。

なお、異なる ADFS ですが同じドメイン / 同じフォレストに所属しているとします。

※ かなり限定的なシナリオですね

実際、オンプレミスにある ADFS / ADFS Proxy の環境を環境として残しつつ、別のエンドポイント URL として、Azure 上に ADFS / Web Application Proxy をたてて移行するシナリオで使いました。

移行先のADFSサーバー上で作業します。
Windows Azure Active Directory モジュールを含む PowerShell を起動。
Office 365 テナントに接続します。

Connect-MsolService

現状の登録済みドメインがどういったフェデレーション設定になっているか確認します。

Get-MsolDomainFederationSettings -DomainName <登録済みドメインFQDN>

⇒ 移行元の設定がずらっと表示されます

ADFS のコンテキストを設定します。

Set-MsolADFSContext -Computer <ADFSサーバーのFQDN (ローカルで接続可能な・・・ ex. fssrv.contoso.local)>

フェデレーションの設定を変更します。

Update-MsolFederationDomain -DomainName <登録済みドメインFQDN>

最後に再び、設定を確認します。

Get-MsolDomainFederationSettings -DomainName <登録済みドメインFQDN>

移行先の設定に変更されていれば完了です。

簡単な作業ですね。

Azure: 復旧サービスで自己署名をアップロードする際のエラー

2014-04-08T20:09:00.001+09:00

Microsoft Azure の復旧サービスの検証を行おうと試みていたのですが、その際に引っかかったポイントを取り急ぎ１つ。

このドキュメントを参考に作業してたのですが、

Windows Server のバックアップをすばやく簡単に行うための Windows Azure 復旧サービスの構成
http://azure.microsoft.com/ja-jp/manage/services/recovery-services/configure-a-backup-vault/

証明書作成ツール (makecert.exe) で自己署名を作成して、Azure の復旧サービスへ登録する際にうまくいきませんでした。

出力されたエラーはこんな感じ。

Invalid certificate uploaded. Please verify that the certificate is not expired, has at least 2048 bit key, enhanced key usage is Client Authentication and expiration date is not more than 3 years from current date.

どうやら、有効期間が3年以内のものでないといけないみたいです。

で、先ほどの手順のURLを英語版に変更してみると、makecert.exe のコマンドサンプルに違いがある事が判りました。

Configure Azure Backup to quickly and easily back-up Windows Server
http://azure.microsoft.com/en-us/documentation/articles/backup-configure-vault/

<コマンドサンプル>
失敗したコマンド：日本語の URL に記載されているもの
makecert.exe -r -pe -n "CN=CertificateName" -ss my -sr localmachine -eku 1.3.6.1.5.5.7.3.2 -len 2048 "CertificateName.cer"

成功したコマンド：英語の URL に記載されているもの
makecert.exe -r -pe -n "CN=CertificateName" -ss my -sr localmachine -eku 1.3.6.1.5.5.7.3.2 -len 2048 -e 01/01/2016 "CertificateName.cer"

"-e 01/01/2016" という記載が増えています。

出力されたエラーの内容とも合致するので納得です。

とりあえず、証明書の部分はこれで問題なさそうです。
ただ、ちゃんと証明書の期限切れ管理を行っていかないといけないですね。

Office 365: ディレクトリ同期環境下で Exchange Online の階層型アドレス帳を有効にする

2014-03-28T00:38:00.000+09:00

先日、Exchange Online でも利用可能になった階層型アドレス帳ですが、ディレクトリ同期を行っている環境下においては、PowerShell で直接オンライン(Azure Active Directory) の属性を変更できない事から、PowerShel での設定だけではうまくいきません。

ディレクトリ同期環境下での管理のセオリーは、”属性の変更はオンプレミス側でしろ” なので、オンプレミスの Active Directory の属性を構成する事で、Exchange Online の階層型アドレス帳を有効にする方法を試してみました。

グループ(配布グループやメールが有効なセキュリティグループ) の階層作成の方法についてはディレクトリ同期を使っていない場合と同じで、階層にしたいグループをネストする形で階層を作成し、必要なグループにユーザーを追加すればグループ側の下準備は完了です。

ちなみに、階層型アドレス帳の部署としてサポートされている配布グループは、メールが有効な配布グループとメールが有効なセキュリティグループです。動的配布グループは階層型アドレス帳の部署としてサポートされません。

Exchange Online にて階層型アドレス帳を有効にする為に必要となる属性は以下の３つ。

[IsHierarchicalGroup]
[SeniorityIndex]
[PhoneticDisplayName]

この３つの属性が Exchange Online のユーザーやグループの属性で変更される必要があります。
しかし、この３つの属性はオンプレミスの Active Directory の属性として探しても見当たりません。

調べた結果、上記の属性と紐づきがある Active Directory の属性が存在するようです。
右側の Active Directory の属性を設定する事で、左側の Exchange Online の属性に同期されるとの事。

(左) Exchange Online側 = (右) Active Directory側
[IsHierarchicalGroup] = [msOrg-IsOrganizational]
[SeniorityIndex] = [msDS-HABSeniorityIndex]
[PhoneticDisplayName] = [msDS-PhoneticDisplayName]

ただ、この右側の Active Directory 側に必要な属性は通常の構成では存在しません。
属性の３つとも Exchange Server に必要な属性として拡張されるスキーマ属性となります。

という事で、

　ディレクトリ同期環境下において Exchange Online の階層型アドレス帳を有効に
　する為には、オンプレAD に Exchange のスキーマ拡張が必須！

という事になります。

既に Exchange Server 2010 以降を導入済みのユーザーにとっては存在するはずの属性なので、以下のスキーマ拡張作業は必要ありません。

■ 階層型アドレス帳の為のスキーマ拡張

スキーマの拡張方法ですが、ちゃんと情報がありました。

Exchange Server 2010 サーバーで階層型アドレス帳 (HAB) 用に Active Directory スキーマを拡張する方法
http://support.microsoft.com/kb/973788/ja

Exchange Server 2010 用の情報ですが、必要となる３つの属性の要件は満たしています。

注) Active Directory のスキーマ変更は大変注意が必要な作業ですので、十分な検証を行った上で、自己責任のもとで行ってください。

上記の KB に記載されているサンプルの LDIF ファイルの内容と、ディレクトリ同期ツールで同期される項目を照らし合わせた結果、以下の項目については、今現在として 必要はありません。
(同期される項目として含まれていません)

<属性追加>
msExchHABRootDepartmentLink
msExchHABRootDepartmentBL
msOrg-GroupSubtypeName
msOrg-OtherDisplayNames
msOrg-Leaders
msOrg-LeadersBL

<属性の設定(上記に加え)>
location

当然、将来的な拡張を見据えた属性の可能性もあるので、全ての項目を拡張される事をお勧めします。

ちなみに、勝手ながら必要な項目だけにスリム化した LDIF サンプルを作成してみました。

dn:CN=ms-DS-Phonetic-Display-Name,DC=X

changetype:ntdsSchemaAdd

adminDescription:ms-DS-Phonetic-Display-Name

adminDisplayName:ms-DS-Phonetic-Display-Name

attributeID: 1.2.840.113556.1.4.1946

attributeSecurityGuid::VAGN5Pi80RGHAgDAT7lgUA==

attributeSyntax: 2.5.5.12

isSingleValued:TRUE

lDAPDisplayName:msDS-PhoneticDisplayName

mapiId: 35986

name:ms-DS-Phonetic-Display-Name

oMSyntax: 64

objectCategory:CN=Attribute-Schema,DC=X

objectClass:attributeSchema

rangeLower: 0

rangeUpper: 256

schemaIdGuid::5JQa4mYt5UyzDQ74endv8A==

searchFlags: 5

showInAdvancedViewOnly:TRUE

systemFlags: 16

systemOnly:FALSE

dn:CN=ms-DS-HAB-Seniority-Index,DC=X

changetype:ntdsSchemaAdd

adminDescription:Contains the seniority index as applied by the organization where the person works.

adminDisplayName:ms-DS-HAB-Seniority-Index

attributeID: 1.2.840.113556.1.4.1997

attributeSecurityGuid::VAGN5Pi80RGHAgDAT7lgUA==

attributeSyntax: 2.5.5.9

isMemberOfPartialAttributeSet:TRUE

isSingleValued:TRUE

lDAPDisplayName:msDS-HABSeniorityIndex

mapiId: 36000

name:ms-DS-HAB-Seniority-Index

oMSyntax: 2

objectCategory:CN=Attribute-Schema,DC=X

objectClass:attributeSchema

schemaIdGuid::8Un03jv9RUCYz9lljaeItQ==

searchFlags: 1

showInAdvancedViewOnly:TRUE

systemFlags: 16

systemOnly:FALSE

dn:CN=ms-Org-Is-Organizational-Group,DC=X

changetype:ntdsSchemaAdd

adminDescription:ms-Org-Is-Organizational-Group

adminDisplayName:ms-Org-Is-Organizational-Group

attributeID: 1.2.840.113556.1.6.47.2.1

attributeSyntax: 2.5.5.8

isMemberOfPartialAttributeSet:TRUE

isSingleValued:TRUE

lDAPDisplayName:msOrg-IsOrganizational

mapiId: 36061

name:ms-Org-Is-Organizational-Group

oMSyntax: 1

objectCategory:CN=Attribute-Schema,DC=X

objectClass:attributeSchema

schemaIdGuid::C1a3SQdHoEqifOF6Cco/lw==

searchFlags: 16

dn:

changetype:ntdsSchemaModify

replace:schemaUpdateNow

schemaUpdateNow: 1

-

dn:CN=Organizational-Person,DC=X

changetype:ntdsSchemaModify

add:mayContain

mayContain:msDS-HABSeniorityIndex

-

dn:CN=Organizational-Person,DC=X

changetype:ntdsSchemaModify

add:mayContain

mayContain:msDS-PhoneticDisplayName

-

dn:CN=Group,DC=X

changetype:ntdsSchemaModify

add:mayContain

mayContain:thumbnailPhoto

-

dn:CN=Group,DC=X

changetype:ntdsSchemaModify

add:mayContain

mayContain:msDS-HABSeniorityIndex

-

dn:CN=Group,DC=X

changetype:ntdsSchemaModify

add:mayContain

mayContain:msDS-PhoneticDisplayName

-

dn:CN=Group,DC=X

changetype:ntdsSchemaModify

add:mayContain

mayContain:msOrg-IsOrganizational

-

dn:CN=Mail-Recipient,DC=X

changetype:ntdsSchemaModify

add:mayContain

mayContain:msDS-HABSeniorityIndex

-

dn:CN=Mail-Recipient,DC=X

changetype:ntdsSchemaModify

add:mayContain

mayContain:msDS-PhoneticDisplayName

-

dn:

changetype:ntdsSchemaModify

replace:schemaUpdateNow

schemaUpdateNow: 1

-

スキーママスタのドメインコントローラー上で LDIF ファイルを取り込みます。

　LDIFDE -i -f schema_file.txt -c DC=x #SchemaNamingContext

■ グループ / ユーザーへの属性設定

スキーマの拡張が完了したら、拡張した属性に対して必要な設定を行います。
オンプレミスの Active Directory に対して ADSI エディット等で値を変更します。

ちなみに、設定するのは以下の3つの属性です。

[msOrg-IsOrganizational] ・・・ (グループのみ) グループを階層の一部にするか？ [True or False]
[msDS-HABSeniorityIndex] ・・・表示順序の設定。数字が大きい方が上に表示。
[msDS-PhoneticDisplayName] ・・・フリガナの設定。

具体的な変更方法については、こちらが参考になるかと思います。

階層型アドレス帳の展開
http://technet.microsoft.com/ja-jp/library/ee649115.aspx

※ AD サイトや DC が複数ある場合は全ての DC にレプリケーション完了してるか確認しましょう

設定が完了したら、ディレクトリ同期ツールで同期を行います。

FIM Admin ツールで Operation を確認すると、ちゃんと設定した属性が追加されている事が判ります。

■ Exchange Online に対して階層型アドレス帳を有効にする

オンプレミスの Active Directory への設定が完了した後、Exchange Online 特有の設定として、
階層型アドレス帳のルートグループ (最上位のグループ) の設定だけは、Remote PowerShell を使って Exchange Online に対して直接設定を行う必要があります。

Exchange Online へ PowerShell で接続します。接続方法はこちらをご覧ください。

ルートにするグループを指定します。
Set-OrganizationConfig -HierarchicalAddressBookRoot "Contoso,Ltd"

※ このサンプルの場合 "Contoso,Ltd" がグループ名 (Name属性) です

■ Outlook 2007 SP2 以降で確認する

階層型アドレス帳は Outlook 2007 SP2 以降で動作します。(OWA では動きません)
メールの宛先等の選択画面にて、[ 組織 ] タブが増えていれば成功です。

ディレクトリ同期ツールを導入済みの Exchange Online ユーザーの方で、階層型アドレス帳の導入をされる方のご参考になれば。

Office 365: Access Web アプリのデータを Excel で利用する

2014-03-27T00:17:00.000+09:00

SharePoint Onlone 上で利用可能な Access Web アプリですが、Access 2013 クライアントから作成・編集をして、簡単に作成可能なフォームで簡単なデータベースを作成する事が可能です。データは 1GB までという制限はあるものの、SQL Azure に格納されるようです。

非常に有用に活用できそうなのですが、実際にデータを入力していくと、それを活用する事も考えないといけません。一番、データを活用するのに適しているアプリという事で、Access Web アプリで入力したデータを、Excel 2013 からアクセスして利用する方法について書いておきたいと思います。

っというのも、結論から言うと Excel から Access Web アプリのデータベースにアクセスする為には、SQL Naitive Client 経由でアクセスする必要があり、通常の SQL Server との外部データ連携ウィザードではアクセスできません。

というか、やり方は調べているうちに見つけたこちらの Blog を試してみた結果です (笑)

Visualize your Access 2013 web app data in Excel
http://blogs.office.com/2013/01/22/visualize-your-access-2013-web-app-data-in-excel/

手順通りに・・・
Access Web アプリを Access 2013 で開きます。
そして、[ファイル] からバックステージを開き、[情報] セクションを開きます。
ここに SQL Azure データベースの情報が表示されています。

さらに詳しい情報を表示する為に、接続の [管理] を開き、 [読み取り専用接続を有効にする] をクリックします。

そうすると、設定が変更され、データベース側で読み取りの設定が可能になります。
再び、接続の [管理] を開くと無効になっていたメニューが選択可能になっていて、[読み取り専用接続の情報を表示] を選択すると、"SQL Server の接続情報" が表示され、ユーザー名やパスワードなどの情報も入手する事が可能です。

この情報を使って、Excel からデータベースに対してアクセスすれば良いという事になります。
で、Excel を開き、[データ] タブの [その他のデータソース] にある [SQL Server] で接続したい所なのですが、上記の設定を使ってもエラーでアクセスができません。

クライアントの IPアドレスが Azure の Firewall で許可されていないという事らしいです。もちろん、Azure マネージメントポータルへのアクセス権もありません。

で、解決方法として上記でも記載しましたが、SQL Server Native Client 経由であればアクセス可能です。

再び、Excel の [データ] タブの [その他のデータソース] にある [データ接続ウィザード] を選択します。

[データ接続ウィザード] にて [その他/詳細] を選択します。

[データリンクプロパティ] の [プロバイダー] の選択にて、[SQL Server Naitive Client 11.0] を選択します。

[ 接続 ] タブに移動して、上記の Access バックステージにて取得した "SQL Server 接続情報" を元に、"サーバー名" "ユーザー名" "パスワード" "データベース名" を入力して、[ 接続テスト] を行い、問題なければ [ OK ] をクリックします。

もし、接続テストでうまくいかない場合は、Access に戻り、接続の [管理] を開き、 [この場所] を選んで、現在のPCからの接続を許可するように設定を変更してください。

[ データ接続ウィザード ] を進めます。ここからのデータベースとテーブルの選択等は適宜。

このように、ピボットテーブルのフィールドとして取り込むことができました。

Excel 以外のアプリケーションでも応用が利きそうです。
ちなみに、昨今話題の PowerBI の Power Query だと、もう少し簡単に取り込むことが可能なようです。

Windows: XP のサポート切れメッセージ

2014-03-26T07:34:00.000+09:00

今更ながらのネタです。
噂の Windows XP に対するサポート終了のお知らせって、Windows Update で配布されるんですね。。。 KB2934207

っという事は、WSUSで止めておけば良かったのかな？

ちなみに、適用するとマシンの起動時にこんなメッセージが表示されます。

ん？終了する日が違う？ってのはご愛嬌。。。

Office 365: 現行 Office 365 (2013版) で Office 2010 Subscription版は使える？

2014-03-25T19:46:00.000+09:00

以前の 2010バージョンベースの Office 365 に、ダウンロード・使用可能だった Office クライアント (Office Professional Plus 2010) のインストールファイルを偶然発見したので、現在の Office 365 サブスクリプション (2013 ベース)下でも有効なのか試してみました。

当時は、Wave 14 と言われていた頃です。今のバージョンは Wave 15。
ちなみに、クライアントは Windows 7 SP1 を使ってます。

普通に実行してインストールしてみます。

という事で、インストールに関してはまったく問題ありませんでした。

で、インストール後に Microsoft Online Services サインインアシスタントのインストールを求められます。これも当時と変わらず。

ここで、サインインを求められるので、現行の Office 365 の ID / パスワードを入力してみました。

普通にサインイン完了。
何か、変なエラーメッセージは出ましたが・・・環境の問題のようなので無視。

肝心の Office のライセンス認証はどうなってるのかというと、、、
まったく問題ありませんでした。ライセンス認証されています。

Office Professional Plus 2010 のサブスクリプション版の認証に、現行の Office 365 の Office 365 ProPlus 使用権を利用する事は可能なんですね。ただ、ライセンス許諾的にはどうなのか調べてないので悪しからず。「"できる" 事と "やっていい" 事は違う」ので。。。実際に使う人はマイクロソフトさんにお問い合わせください。

１点気になったのは、Office 365 ポータルで Office のソフトウェアの認証状況確認画面には変化がありませんでした。該当のコンピューター名 / オペレーティングシステムが Windows 7 のもの / インストール日が見当たらず。。。

という事で、結果、怪しい結果になりましたが、とりあえずまだ動くようです。

ちなみに、コンパネの "プログラムと機能" はこんな感じです。(普通)

Office365: Outlook Web App のエディタ機能が良くなった

2014-03-12T20:59:00.000+09:00

久々に Office 365 ネタも。

Office Web Apps が Office Online になっても Outlook Web App のままの Exchange Online ブラウザアクセス機能ですが、テキストエディタの機能が強化されたようです。

Enhanced text editor in Outlook Web App
http://blogs.office.com/2014/03/11/enhanced-text-editor-in-outlook-web-app/

ただ、YouTube のリンクなどを張り付けれる Rich hyperlink previews はまだ動きませんでした。その他は問題なく動作しました。

・ペースト機能のオプション
　　フォント付テキストや Excel で作ったグラフなどをコピー&ペーストする際に便利になります。

・表の作成とカスタマイズ
　　本文中に表を作成して、更に見栄えの良い表にしたりできます。

Office App ストアも充実してきており、更に Outlook Web app のカスタマイズもしやすくなってるみたいなので、今後、3rd Party アプリも含め期待したいと思います。

Azure: AzureVM に固定IPを割り当てる

2014-03-11T20:42:00.000+09:00

これまで Azure VM は DHCP から割り当てられた Private IP を使用するしかありませんでした。(実際に割り当てられた Private IP が変更される事はほぼ無いですが・・・)

どうやら、それが固定IPを割り当てる事が可能になったようです。
# 正確には、DHCP で割り当てられる IP を指定できるようになった

2月の Azure SDK の Update からみたいですね。

Windows Azure PowerShell を起動して、サブスクリプションに接続します。
⇒ この辺は SEの雑記さんで判りやすくご説明されているのでご覧ください

あとは以下のコマンドで可能です。

$VM = Get-AzureVM -ServiceName <サービス名> -Name <VM名>
Set-AzureStaticVNETIP -VM $VM -IPAddress <IPアドレス> | Update-AzureVM

※ VM が起動している場合、再起動が走ります。

固定 IP になる訳ではありません。

=== 2014/03/12 追記 ===

どうやら、固定 IP の割り当てを行う度 (Set-AzureStaticVNETIP) に仮想マシン上のネットワークカードが変更されているようです。
上記の状態から、再度割り当てる IP を変更すると "Ethernet 5" から　"Ethernet 6" に増えました。変更するたびに内部的にゴミが残っていきそうですね。。。

あと、試しに割り当てた IP を仮想マシンの IPv4 NIC に固定 IP として設定してみたところ、、、
接続していたリモートデスクトップ接続が見事に切断されました。設定した値が悪かったのかな？

仕方ないので、ネットワークカードが変更される点を利用して、Set-AzureStaticVNETIP で割り当てる固定IPを再度設定したら、DHCP に戻って再度リモートデスクトップで接続できるようになりました。

Azure: マイクロソフトが日本にAzure用データーセンターを開設！

2014-02-25T12:03:00.000+09:00

以前から発表はされていましたが、マイクロソフトがAzure用のデーターセンターを日本に開設したそうです。

Windows Azure日本データセンターサービス開始!
http://satonaoki.wordpress.com/2014/02/25/azure-japan-dc/

Amazon Web Services (AWS) や Salesforce は以前から日本にデーターセンターを開設していましたが、マイクロソフトも追随する形で、更に、一気に２か所も開設です。
(国内のみで冗長構成が組めるって事ですね)

すでに IaaS （仮想マシン) でも「日本（東）」と「日本（西）」が選択できます。

Office 365: Exchange Online で階層型アドレス帳が利用可能に！ (ただしOutlookだけ)

2014-02-24T12:52:00.000+09:00

2/20のBlogで発表がありました。

Hierarchical Address Book now available in Office 365 too
http://blogs.technet.com/b/exchange/archive/2014/02/20/hierarchical-address-book-now-available-in-office-365-too.aspx

やり方はオンプレミスと同じとの事。
同期対象(DirSync?) にはなってないので、近い将来まで待ってね。
今現在は Outlook 2010 / Outlook 2013 のみ対応だよ。今現在は。。。

という事なので、試してみました。

階層型アドレス帳を有効または無効にする
http://technet.microsoft.com/ja-jp/library/ff607473(v=exchg.150).aspx

HAB(Hierarchical Address Book = 階層型アドレス帳)は、PowerShellでしか設定できないので、Exchange Online へ PowerShell で接続します。接続方法はこちらをご覧ください。

オンプレミスの場合、"HAB"というOUを作成するように書かれてますが、オンラインなので OU を変更する事は出来ない為、そのまま手順を進めます。

まずは、ルート配布グループの作成。もろもろは適宜変更してください。
New-DistributionGroup -Name "Contoso,Ltd" -DisplayName "Contoso,Ltd" -Alias "ContosoRoot" -Type "Distribution"
※ "OrganizationalUnit" と "SamAccountName" は省略可能なようです
※ Type は "メールが有効なセキュリティグループ" (-Type Security) でも可能です

作成したグループを HAB のルート組織として指定します。
Set-OrganizationConfig -HierarchicalAddressBookRoot "Contoso,Ltd"

必要な階層 (部署名等) 分の配布グループ (メールが有効なセキュリティグループでも可) を作成します。
作成したグループを "階層型グループ" として指定します。
Set-Group -Identity "Contoso,Ltd" -IsHierarchicalGroup $true
※ ↑このように最初に作成したルート配布グループにも設定するのを忘れずに
※ 階層にする全てのグループに対して設定します

作成したグループを、上位のグループのメンバー(ネスト)に設定します。
Add-DistributionGroupMember -Identity "ContosoRoot" -Member "CorporateOffice"

最終的に、グループのメンバーにユーザーを追加します。
Add-DistributionGroupMember -Identity "CorporateOffice" -Member "田中太郎"

-SeniorityIndex を使用する事で、グループ内の表示順序を並び替える事も可能です。

設定が完了したら Outlook 2010 か Outlook 2013 で階層型アドレス帳が有効になって、意図した階層になっているかを確認します。設定が反映されていない場合は、オフラインアドレス帳を更新するなどを試してみてください。

とりあえず、Outlook 2010 / Outlook 2013 でオンプレミスとの大きな差が１つ解消されました。

Outlook Web App (OWA) でも階層型アドレス帳が使えるようになる日は来るのでしょうかねぇ～

Windows 2012: 証明書サービス Web 登録構成時のエラー対処

2014-01-16T19:52:00.000+09:00

かなり個人的な備忘です。

Active Directory 証明書サービスの証明機関 Web 登録をインストール後に構成を行おうとしたのですが、エラーになりました。

証明機関 Web 登録 - 構成に失敗しました
Active Directory 証明書サービスのセットアップは、次のエラーで失敗しました：パラメーターが間違っています。0x80070057 (WIN32: 87 ERROR_INVALID_PARAMETER)

原因は、"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\CertSvc\Configuration" の "SetupStatus" が証明機関 Web 登録が既にインストールされている事を表す 6003 (16進数) となっているとの事。未インストールの場合、 6001 (16進数) となっている必要があるとの事。

レジストリエディタ (RegEdit) で修正、もしくは、PowerShell から "certutil -setreg config\setupstatus 0x6001" と実行すれば解決できます。

※ 変更後、CertSvc サービスの再起動が必要です

(参考) AD: Certification Authority Web Enrollment Configuration Failed 0x80070057 (WIN32: 87)
http://social.technet.microsoft.com/wiki/contents/articles/12035.ad-certification-authority-web-enrollment-configuration-failed-0x80070057-win32-87.aspx

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

2014-01-09T19:30:00.000+09:00

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

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

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

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

ただし、これが行えるには条件があります。

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

という事で、まだまだ今後使える機能という感じですね。

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

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

Edition	AVMA Key
Datacenter	Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
Standard	DBGBW-NPF86-BJVTX-K3WKJ-MTB6V
Essentials	K2XGM-NMBT3-2R6Q8-WF2FK-P36R2