Office365 Offcatが5月にEOSとなるようです。そしてようこそSaRaの世界へ

Office(主にOutlook)がOffice365で利用できるような状態かどうかをチェックするツールとしてOffcatというツールがあるのですが、これが2018年5月31日をもって提供終了となるようです。

OffCAT’s replacement – Microsoft Support and Recovery Assistant (SaRA) – You Had Me At EHLO…

このツールでは、Office365に接続するためのパッチが当たっているか(Office2010や2013では、初期状態ではOffice365には接続できず、一部の更新パッチを導入する必要があります)をチェックしたり、対象PCのレジストリ情報を解析したりすることができました。

特にレジストリ情報の取得は外部からAutodiscoverの設定が正しくなっているかなどを調べるのに有用で、私もよく利用していたので、1か月で終了するというスピード感に驚いています。

この5月を過ぎるとダウンロードができなくなり、かつ更新が止まるため、最新の状況が追えなくなるという状態になるのですが、スキャンなどは引き続き行えるようなので今後に備えてダウンロードしておくというのも有効化と思います。

【Offcatはこちら】

https://support.microsoft.com/ja-jp/help/2812744/office-configuration-analyzer-tool-offcat-information

なお、今後はOffcatの役割はSaraというツールに置き換わっていきます。

Fix Outlook and Office 365 problems with the Microsoft Support and Recovery Assistant for Office 365

SaRaの場合、Offcatのようの情報を取得するという形ではなく、対応する問題に対し、解決策を与える。という形の作りとなっています。上記URLからダウンロードしインストールする形となります。(SetupProd.exe)

最近はClick onece形式が多いですねぇ、、

f:id:mohessu:20180420013108p:plain

最初にServices Agreementを読んでおきましょう。

f:id:mohessu:20180420015344p:plain

同意後はそのままセットアップになります。5分ほどでインストールは完了です。

f:id:mohessu:20180420015403p:plain

セットアップが完了すると問題の発生しているアプリを選択する画面に。
為にしOutlookをえらびましょう。(OutlookはAutodiscoverの動き等、自動化の仕組みがややこしくしていたりするので、一筋縄ではいかないんですよねぇ、、、いつも)

f:id:mohessu:20180420015534p:plain

次に発生している問題を確認します。
この辺りはOffcatにはなかった利点です。

f:id:mohessu:20180420015607p:plain

続いて問題発生PCか確認が入ります。

f:id:mohessu:20180420015615p:plain

問題が発生しているPCの場合、Office365へのログインが促されます。本当はこの辺はADAL認証になってほしいところです、、、

f:id:mohessu:20180420015638p:plain

サインイン情報を入力してしばらく待っていると、結果が表示されます。

f:id:mohessu:20180420021533p:plain

ツール自体が簡単に、誰でもわかるようになったのは喜ばしいところですね。
詳細な状態がとりたい場合は高度な診断を行うことでOffcatの代替は務まるかと思います。

Offcat、SaRa、どちらも有用な機能なので、ぜひ覚えておきましょう。

音楽:Shadow

Windows 10 Build 17134リリース

なんとリリース目前となっていたWindows 10 Build 1803ですが、Insider Preview Buildが一つあがり、Build 17134がリリースされていました。

f:id:mohessu:20180419002948p:plain

Build 17133も、緊急的にパッチが当たっていましたが、それでも改善できない問題が出たため、新たなるBuildを用意した形となっています。

問題の詳細は明らかにされていないのですが、ブルースクリーンが発生するような内容とのこと。要するにカーネル周りに問題が残っていたのかと推測されます。

このBuildで安定しれくれれば、そのままVersion 1803に昇格するものと思われます。

導入する側としては、問題が致命的でなければ予定通りに出荷してもらいセキュリティパッチとして更新をかけてもらった方が、PCのリプレースなどのスケジュールが立てられる分ありがたかったりもしますので、ぜひそういったニーズもあるということを意識してもらい、リリースへと早期にこぎつけていただきたいですね。

さぁ後ひと踏ん張り!Windows 10 Version 1803を楽しみに待ちましょう。

音楽:Cyberbird

Office365 組織のロゴが表示されなくなりました。

Windows 10 のBuild 1803がなかなか出ないと思っていたら、バグがあってまだ出荷にたどり着けていないのではないか。という憶測が飛んでいますが、実際どうなのかと考えながら、Office365をひらいていたら画面上部のカスタムロゴ(企業ロゴ)が表示されなくなっていました。

もともとは管理センター上で、組織のプロファイルからカスタムテーマを適用することで、画面中央上部に企業ロゴが表示できるのですが、いつの間にやら真っ黒な状態で表示されていない状態になっていました。

f:id:mohessu:20180417015653p:plain

設定ミスかとも思い、再度設定してみたものの、出たりでなかったりで不安定な動作になっていました。

【企業ロゴはこんな風に表示されます。(画像は白抜きにしてみました)】

f:id:mohessu:20180417020826p:plain

どうしてかといろいろ調べてみると、2018年5月でこのロゴの出方が変わり、左側のOffice365のマークと入れ替わるようなのです。

おそらくこれが原因で、仕様が徐々に変わっているのかと思われます。

企業ロゴが左側に移動した後は、今のOffice365ロゴを押下した際に遷移するoffice.comへの移動が行えなくなり、アプリランチャーから移動が必要になるとのこと。

些細な変更ではありますが、常に表示されている画面の変更なので、違和感が出ると思います。ユーザーへの通知は怠らないようにしておきたいですね。

【アプリランチャーでは、上部右にOffice365へのリンクがあります。】

f:id:mohessu:20180417021454p:plain

音楽:浜名の風

Windows Active Directoryの構成(Windows Server 2019版)

Adcive Directoryのインストールが終わったら次はActive Direcotry ドメイン サービス構成ウィザードです。

と、その前に、ADドメインで利用するDNSが決まっていない場合は、インストールしておきましょう。

役割と機能の追加ウィザードでDNSサーバーを選択します。

f:id:mohessu:20180415152223p:plain

ツールのインストールを確認されるので、これも合わせて入れておきます。

f:id:mohessu:20180415152246p:plain

増える機能はDNS サーバー ツールのみ。DNSサーバーが一台目であれば入れておきましょう。

f:id:mohessu:20180415152431p:plain

機能説明は特に変わらず。そのままインストールに進んでいきましょう。

f:id:mohessu:20180415152543p:plain

f:id:mohessu:20180415152811p:plain

5分ほどでインストールが完了するので、インストールが終わったらActive Direcotry ドメイン サービス構成ウィザードを起動します。

AD DSの項を開き、上部に表示される黄色地の帯右側のその他をクリックします。

f:id:mohessu:20180415154310p:plain

タスク詳細の操作にこのサーバーをドメイン コントローラーに昇格するリンクが出るので、これを押しましょう。

f:id:mohessu:20180415154446p:plain

するとウィザードが表示されるので、新しいフォレストを追加するを選択します。
ドメイン名は内部利用なので、なんでも良いのですが、昨今のクラウドサービスとの統合を踏まえると、外部ドメインとしておいた方が都合がよいかもしれませんね。
後で変更することはできますが、ちょっと手順が煩雑です。

f:id:mohessu:20180415141606p:plain

次にドメインのレベルを選びます。
デフォルトレベルはWindows Serverとなっています。

f:id:mohessu:20180415141813p:plain

旧バージョンの機能レベルも選ぶことができますが、Windows Server 2016向けのものがありません。

f:id:mohessu:20180415141842p:plain

確かにWindows Server 2016ではなぜか「Windows Server Technical Preview」となっていたので、この点を直したのはわかりますが、やっぱりCALが一本化される兆候なのでしょうか。
なお、DSRMのパスワードは復元時に利用するパスワードとなるので、忘れずに控えておきましょう。

f:id:mohessu:20180415154037p:plain

続いてDNS オプション。
最初のインストールでは親ゾーンは見つからなくても問題ありません。
そのまま次にいきましょう。

f:id:mohessu:20180415162019p:plain

NetBIOS名入力です。最近はTCP/IP DNSばかりなのでおまじない程度で考えてもいいのかと思います。
自動入力されるので、入力済みの名前がドメイン内で被らなければそのまま行きます。

f:id:mohessu:20180415162102p:plain

AD DSのログやデータベースの場所を指定します。

f:id:mohessu:20180415162140p:plain

 内容を確認したら前提条件のチェックに入りましょう。

f:id:mohessu:20180415162301p:plain

前提条件チェックでは、DNSサーバーで親ゾーンが見つからない。というものは新規導入の場合必ず出ます。(上から2番目)

一番上の警告は、、、残念ながら404エラー!(サイトがなくなったようです)

http://go.microsoft.com/fwlink/?linkid=104751

見る限り、セキュアな方に倒したので古いサーバーはつながらない。といっているだけなので、そのまま読み飛ばして大丈夫ですかね。NT4が残っているなら注意が必要です。
なお、IPアドレスが動的になっているともう一つ警告が表示されます。
サーバーなので、IPアドレスは固定にしておきましょう。

f:id:mohessu:20180415165132p:plain

【404エラー、、、】

ちょっと可愛目なエラーです。

f:id:mohessu:20180415174221p:plain

インストールが終了したら利用ができる状態になっています。
GUIの線が太くなったのは、一時的なのだと思いますが、この辺りもFluent Design Systemが適用されてくるのでしょうか。どうなるか見ものですね。

f:id:mohessu:20180415192224p:plain

f:id:mohessu:20180415173846p:plain

音楽:月下美人

Windows Server 2019 ADインストールしてみました

Windows Server 2019 Previewですが、やっぱり一番よく使うActiveDirectoryをインストールしてみましょう。
実際の利用にはCALが必要となりますが、Windows Server 2019でも専用CALが出るのでしょうか、、、

位置づけ的にはWindows 10 Server R2みたいな形とおもっています。
R2のようなリビジョンアップでは従来CALのバージョンアップは不要でした。
(例として、Windows Server 2003/2003 R2、2008/2008 R2、2012/2012 R2では/の前後は同一CALでアクセスが可能だったのです。)
これにのっとって、Windows Server 2016 CALでアクセスできたりしないですかねぇ。

それはさておき、ADをインストールしていきます。
まずはサーバー マネージャーを起動し、右側の管理メニューから役割と機能の追加を押下します。

f:id:mohessu:20180414195224p:plain

開始前の案内がでるので次を押します。
今まで通りですね。

f:id:mohessu:20180414195326p:plain

次にインストールの種類の選択。
これも2016から大きな変更はないですね。
役割ベースまたは機能ベースのインストールを選択します。

f:id:mohessu:20180414195338p:plain

次はサーバーの選択です。
オペレーティングシステムの欄をみると、「Microsoft Windows Server Datacenter」となっており、OSバージョンがなくなっています。

f:id:mohessu:20180414201357p:plain

Windows Server 2016の時】

f:id:mohessu:20180414210110p:plain

次は機能の選択です。Active Directory ドメイン サービスを選択します。

f:id:mohessu:20180414210244p:plain

選択するとActive Directoryドメイン サービスに必要な機能を自動インストールする旨がダイアログで表示されます。

f:id:mohessu:20180414210406p:plain

次に機能。
ここでは再度の選択は不要です。グループ ポリシーの管理とリモート サーバー管理ツールの一部が選択されています。この辺りも変わりなくですね。

f:id:mohessu:20180414212149p:plain

f:id:mohessu:20180414212026p:plain

続いてAD DS設定。
この表示も2016から変更はなさそうですね。

f:id:mohessu:20180414214139p:plain

これでインストール設定は完了です。
(インストール後の構成はこれから残っています。)

問題なければインストールを押しましょう。
インストール時にソースの指定が必要となる場合があります。
その場合は代替ソース パスの指定からソースの場所を選択しましょう。通常は記載の通り、インストールディスクのSourcesフォルダを選択すればOKです。(そもそもインストール時にインストールイメージまで含まれるケースがほとんどですけれどね)f:id:mohessu:20180414214258p:plain

この後は5分程度でインストールが終了します。
素の状態からであれば再起動は求められません。
インストールの後作業として、ドメインコントローラーに昇格する必要があるので、忘れずに実施しましょう。中央のリンクをクリックすると昇格(というか構成)をすることができます。

f:id:mohessu:20180414214921p:plain

音楽:ess

Office365 Autosicover とProxyの関係性の考察

Autodiscoverを利用した際にProxyをどのように経由するか調べてみました。
今回確認を行いたかった点は、Proxy除外設定をしている場合、Redirect設定が動作したときにどういった経路を通っていくか。というところです。
当初想定はRedirect後の設定でConnectするものと思っていましたが、その通りの動きを検証することができました。
順を追って内容を見てみましょう。

ProxyとしてBJDを利用し、念のためWinHTTPはダイレクト接続される設定で確認しました。

f:id:mohessu:20180405012047p:plain

f:id:mohessu:20180405012036p:plain

Autodiscoverはレジストリで既定の動作をするように設定しています。

f:id:mohessu:20180405012627p:plain

まずはProxy除外なしで接続してみます。

f:id:mohessu:20180405011020p:plain

接続のテストはOutlookのテスト機能を利用しました。

f:id:mohessu:20180405013151p:plain

ログです。

上記の動きの通りonmicrosoft.com→autodiscover.onmicrosoft.com→リダイレクトでautodiscover-s.onmicrosoft.comでつながり、応答が返ってきます。

f:id:mohessu:20180405012816p:plain

f:id:mohessu:20180405012952p:plain

続いて名前解決前をProxy除外したケース。

f:id:mohessu:20180405015517p:plain

これも接続は成功しています。

f:id:mohessu:20180405015743p:plain

このケースではAutodiscover~onmicrosoft.comの除外設定を行っているため、ダイレクト接続を期待しましたが、想定通り除外されたようです。

f:id:mohessu:20180405023427p:plain

それならば。と、今度はautodiscover-s~を除外に設定してみました。

f:id:mohessu:20180405020403p:plain

テストの結果は同様に接続されている状態になっています。(Proxyを通しても通さなくても出口は一つなので結果が変わらないのが期待値です。)

f:id:mohessu:20180405020640p:plain

ログです。このケースではoutlook-sには接続に行かない想定でしたが、その通りとなっていました。

f:id:mohessu:20180405023945p:plain

f:id:mohessu:20180405024122p:plain

この辺りを踏まえると、Cnameなどで宛先を変更するようなOffice365の場合、Proxy除外設定を忘れずに設定しておかないとエラーとなってしまいそうです。

設定するときはこの辺りを気を付けて行っていきましょう。

音楽:宵越しの祭り

SharePoint News FeedがEOSとなるようです。

SharePointで長年利用されてきたニュースフィード機能がとうとうEOSを迎えることとなりました。

In June 2018, we're making changes to the native social capabilities in SharePoint Online - Microsoft Tech Community - 178430

以下画面の中央下段のものがニュースフィードですが、昨今の流れとして、ジャーナルのように流れていく情報は、Yammerとか、Teamsとかで流していってほしいという流れなんでしょうね。

f:id:mohessu:20180414011548p:plain

モダンSharePointサイトのカスタマイズ性などを考えると、ファイルのやり取りの部分のみをSharePointに残し、そのほかはすべて別システムに持っていきたいという意向が強いように感じますね。

ニュースフィードは2018年6月より読み取り専用となり、その後利用できなくなるという状態となるようです。それまでにどういった機能で実現していくか検討する必要がありますが、Yammerの埋め込みあたりがちょうどいい感じなんですかねぇ。

音楽:ハイランド クロック