kazuakix の日記

Windows Phone とか好きです

Microsoft Teams のゲストアクセスを試す (その 2)

 少し前から Microsoft Teams に組織外のユーザーが参加できるようになっていました。

 この時は、他のテナントの Office 365 など Azure AD を使っているユーザー限定で誰でも参加できるものではありませんでしたが、いつの間にか一般の Microsoft アカウントも参加させられるようになっていました。


 
 設定は以前と同じく、Office 365 管理者センターから 設定 - サービスとアドイン を開き、Microsoft Teams の 「構成するユーザー/ライセンスの種類」を「ゲスト」に、「この種類のすべてのユーザーに対する Microsoft Team のオンとオフを切り替えます」 を 「オン」 にして保存します。

f:id:kazuakix:20180310221924p:plain

 後は、それぞれのチームでゲストユーザーのメールアドレス (Microsoft アカウント) を入力します。

f:id:kazuakix:20180310222542p:plain

 以前はこの状態で Microsoft アカウントを追加しても、サインインしようとしたときにエラーになっていましたが、今回はあっさりとサインインすることができました。

f:id:kazuakix:20180310223719p:plain
 
 気になるメニューですが、ゲストユーザー (左) は 会議 や追加のアプリ、ストアのボタンがありませんでした。会議については、できれば Outlook.com のカレンダーの内容が表示できたらすごく便利だと思うんですが、今後に期待ですね。

f:id:kazuakix:20180310222658p:plain
 
 ただ、チーム内に追加されたファイルや Wiki などのタブは表示することができました。(さすがにライセンスが必要な Planner は表示できませんでしたが)
f:id:kazuakix:20180310223122p:plain
 
 外部ユーザーが参加できるようになることで、利用できるシーンが増えそうですね。

PowerShell で Office 365 に接続する (2018.02 版)

 フォーラムで見かけたのですが、少し前から PowerShell で Office 365 に接続するためのツールである Microsoft PowerShell の Microsoft Azure Active Directory モジュールのインストール方法が変わっています。
 
 Office 365 PowerShell への接続の記事中では、ツールをインストールするために「Azure Active Directory Connection の Web ページを開きます」と書かれているのですが、実際に開くと、「Microsoft Connect は無くなったので、Microsoft Collaborate を見てね」というページが表示れます。

f:id:kazuakix:20180205204912p:plain

そして Microsoft Collaborate のページを探しても、それらしいツールを見つけることはできません。
 
 今 (2018 年 2 月現在) 、PowerShell で Office 365 に接続する手順は以下のようになっています。

1. Microsoft Online Services サインイン アシスタントの 64 ビット バージョンをインストール

IT プロフェッショナル 用 Microsoft Online Services サインイン アシスタント RTW からダウンロードしてインストールします。
 

2 . PowerShell から Microsoft PowerShell の Microsoft Azure Active Directory モジュールをインストール

 PowerShell を管理者として実行し、 Install-Module を使ってモジュールをインストールします。 (途中の選択肢はどちらも Y を選んでおきます)

Install-Module -Name MSOnline

f:id:kazuakix:20180205210224p:plain
 
 あとは、Connect-MsolService コマンドレットでこれまで通り Office 365 に接続することができます。

$UserCredential = Get-Credential
Connect-MsolService -Credential $UserCredential

 ちなみに、二要素認証を使っている場合は単に Connect-MsolService とするだけで接続できます。(標準の Get-Credential と違って、何故か妙に縦に長いダイアログが表示されますね)

Connect-MsolService

f:id:kazuakix:20180205210928p:plain
 
 このあたりの詳細は Azure Active Directory の PowerShell モジュール の記事に記載があります。また、英語版のドキュメントではすでに正しく記載されていますので、日本語版ドキュメントもそのうち修正されると思います。

f:id:kazuakix:20180205211450p:plain

ASP .NET Core で作った Web API を Linux サーバーでホストしてみる

 Linux を使って ASP .NET Core を使ってみようとしてハマった事のメモです。

やりたかった事

 フロントエンドで接続を受け付けて、AP サーバーを呼び出す平凡な構成を考えてみます。インターネットからの接続を Nginx をリバースプロキシにして ASP .NET Core の Kastrel を呼び出します。

f:id:kazuakix:20180203160341p:plain

 この辺のドキュメントを参考に環境構築して、Windows で作った実行ファイルを Linux にコピーして実行してみました。
 
プロジェクトの作成

mkdir ShinjiLocation
cd ShinjiLocation
dotnet new webapi

f:id:kazuakix:20180203171748p:plain
 
実行ファイルの作成

dotnet publish -C Release

f:id:kazuakix:20180203170801p:plain
 

その 1) Windows と Linux のバージョンをあわせる

 Windows 作った空のプロジェクトを Linux で実行しようとしたところ、エラーが出てしまいました。

f:id:kazuakix:20180203171914p:plain

[root@ap01 ShinjiLocation]# dotnet ShinjiLocation.dll
Error:
  An assembly specified in the application dependencies manifest (ShinjiLocation.deps.json) was not found:
    package: 'Microsoft.AspNetCore.Antiforgery', version: '2.0.1'
    path: 'lib/netstandard2.0/Microsoft.AspNetCore.Antiforgery.dll'

 
 Windows で作ったプロジェクトと Linux で作ったプロジェクトを比較すると、.csproj で指定されているライブラリのバージョンが違っていました。
 
Windows で作ったプロジェクト

<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.5" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.2" />
</ItemGroup>
</Project>

 
Linux で作ったプロジェクト

<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.0</TargetFramework>
</PropertyGroup>
<ItemGroup>
<Folder Include="wwwroot\" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.All" Version="2.0.0" />
</ItemGroup>
<ItemGroup>
<DotNetCliToolReference Include="Microsoft.VisualStudio.Web.CodeGeneration.Tools" Version="2.0.0" />
</ItemGroup>
</Project>

 今回は、Windows で作ったプロジェクトの Microsoft.AspNetCore.All と Microsoft.VisualStudio.Web.CodeGeneration.Tools のバージョンを Linux で作ったプロジェクトにあわせることで回避しました。

 この件について、後日 id:shibayan に聞いたところ、親切に .NET Downloads を見るように教えてくれました。

f:id:kazuakix:20180205214626p:plain

 確かに yum コマンドで確認すると、複数のバージョンが登録されています。

f:id:kazuakix:20180205215811p:plain

 インストールするとき、ドキュメントのサンプルそのままに古いバージョン (2.0.0) を指定してしまっていたのが原因でした。インストール前にはちゃんと最新バージョンをチェックしないといけないですね。
  

その 2) localhost 以外から Kastrel に接続できるようにする

 Linux サーバーで Web API が実行できるようになったので、リバースプロキシ経由でアクセスしてみようとしたのですが、別のサーバーから接続することができませんでした。

 設定項目らしきものも見当たらず、手詰まりになりそうだったので、アメリカに出張中の id:okazuki に助けを求めたところ、T ボーンステーキの画像と一緒に、以下の URL が送られてきました。

f:id:kazuakix:20180203164729p:plain

 どうやら、Program.cs にある BuildWebHost 関数の中で Kestrel に関するパラメーターを指定できるようです。

 早速、UseKestrel に Listen オプションだけを指定して UseStartup と Build の間に追加したところ、無事に別ホストのリバースプロキシ経由でアクセスできるようになりました。

public static IWebHost BuildWebHost(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        .UseStartup<Startup>()
        .UseKestrel(options =>
        {
            options.Listen(IPAddress.Any, 5000);
        })
        .Build();
    }
}

 
 とまぁ、こんな感じでようやく実行環境ができました。(Azure 使ってたらこんな事するまでもなかったんだとは思いますが...) あとは中身を作っていくだけですね!