その名の通りです。私は比較的、頻繁にみているサイトの一つです。
追加された機能は勿論ですが、Office の楽しい使い方が公開されているサイトです。
例えば、PowerPoint で 3D モデルを挿入してみる等、「あっ、こんなんあったんねｗ」と思わず口に出してしまいそうになります。
TITLE : What’s new in Office 365
URL : https://support.office.com/en-us/article/what-s-new-in-office-365-95c8d81d-08ba-42c1-914f-bca4603e1426
オンプレミスの Active Directory ユーザーを元にディレクトリ同期を Exchange Online にするシナリオは多くあります。
また、多くの場合、テナントユーザーは、単一の SMTP アドレスを持つのみでシンプルに利用されている企業様が多いようです。
しかしながら、今まで利用していたアドレスを継続的に利用しつつ、企業統合により新たな SMTP アドレスを利用するというシナリオもあります。
本投稿では、オンプレミスの Active Directory を元にして複数のメールアドレスを付与する方法を記載します。
————-
$user=Import-Csv “C:\ChangeProxyAddresses.csv”
#define domain here
$domain=”contoso.com”
$domain2=”example.com”
#adding proxies
$SMTP1=”SMTP:”
$sip=”sip:”
$Smtp2=”smtp:”
#adding all
$SMTP1=$SMTP1 + $user.proxyaddress + $domain
$SMTP2=$SMTP2 + $user.proxyaddress2 + $domain2
$sip= $sip + $user.sip + $domain
foreach ( $user in $users)
{Get-ADUser $user.username | set-aduser -Add @{Proxyaddresses=”$SMTP1″}
Get-ADUser $user.username | set-aduser -Add @{Proxyaddresses=”$smtp2″}
Get-ADUser $user.username | set-aduser -Add @{Proxyaddresses=”$sip”}
}
————-
米国の Microsoft Blog タイトルそのままですが、そのタイトルの通り、クライアントあるいは管理者は、Office のライフサイクルと Office 365 への接続互換性要件が明確に変更されることを意識する必要があります。
このBlog では、2020 年にメインストリームサポートあるいは Office 365 を利用していないレガシー Office については、Outlook 、OneDrive、Skype for Business からの Office 365 への接続をサポートしないということです。
ただ、サポートしないのではなく接続ができなくなるとありますので、Windows OS のアップグレードに伴い、Office についても留意したバージョンに更新する必要があります。
– 出典
TITLE : Office 365 system requirements changes for Office client connectivity
URL : https://techcommunity.microsoft.com/t5/Office-365-Blog/Office-365-system-requirements-changes-for-Office-client/ba-p/62327
SIP アドレスを大量に変更する作業がありました。
その際に、ヒヤリとしたので、Blog にアップします。通常 Lync Server 上でユーザーの SIP アドレスを変更すると Lync Address Book の更新反映による影響などで、クライアントが Lync 連絡先に登録している他ユーザー (ここでは SIP アドレスを変更したユーザーとしましょう) のプレゼンスや IM が正しく行われないことが多く発生します。
今回のヒヤリは、Lync 応答グループに登録しているグループ内のエージェント情報が古いまま全く変わらず、Lync Address Book の更新をして １～２時間まっても更新されない状態になりました。
– 解決策
結果的に、Lync 応答グループ サービスの再起動をすべてのフロントエンドで実施したところ変更した SIP アドレスが更新されました。
応答グループ内のエージェント SIP アドレスが更新されないということは、応答グループに着信した Call がエージェント SIP アドレスに到達しないことを意味しますので業務に甚大な影響を与えるという事になります。
また、このヒヤリで気付いたのが解決策を実施しても SIP アドレスが変わらないエージェントが存在することでした、アドレスを調べてみると既に AD 上あるいは SIP アドレスを持たないエージェントであることが分かりました。
そうです。応答グループのグループエージェント情報は AD と Lync Server が持つ情報と完全同期はしていないということです。開発元である Microsoft でも同様に再現したので、以下のようなスクリプトを定期的に実行し一覧化することで、応答グループのグループエージェントの棚卸しはした方が良いと考えます。
—————— ここから——————
#Import-Module ‘C:\Program Files\Common Files\Microsoft Lync Server 2013\Modules\Lync\Lync.psd1’
$Output = (“$env:USERPROFILE\Desktop\” + (Get-Date -Format “yyyyMMdd-HHmmss”) + “-RgsAgentGroupList.csv”)
$RgsAgentGroups = Get-CsRgsAgentGroup
foreach ($RgsAG in $RgsAgentGroups)
{
$Agents = $RgsAG.AgentsByUri
foreach ($Agent in $Agents)
{
$Agent | Add-Member -Type NoteProperty -Name RgsAgentGroupIdentity -Value $RgsAG.Identity
$Agent | Add-Member -Type NoteProperty -Name RgsAgentGroupDisplayName -Value $RgsAG.Name
$Agent | Export-Csv -Path $Output -Encoding Default -NoTypeInformation -Append
}
}
—————— ここまで——————
Office 365 を利用する上で、自社ドメイン (etc: contoso.com) 利用して、それが提供するサービスの名前解決をすることがほとんどだと思います。
Office 365 には、DNS に登録するレコードにいくつかの要件があります。
大きく3 点です。
1. テキストレコードの登録をサポートする事
2. 別ドメインをターゲットとする CNAME レコードの登録をサポートする事
3. サービス レコード (SRV) の登録をサポートする事
しかしながら、SRV (サービスレコード) はマイクロソフト社が利用するレコードとなっており DNS サービス側が対応していないタイプのレコードです。
SRV レコードが登録できない場合の影響度としては、以下となります。
必ずしも必須の機能ではないということであれば、SRV レコードをサポートしてない DNS サービスを利用しても構いませんが、コミュニケーションの範囲を広げていきたい企業にとっては、サポートしている DNS ホスティングサービスの利用を検討することをお薦めします。
尚、SRV レコードが登録できない場合の制約は以下の通りです。
SRVレコード (_sipfederationtls._tcp. ドメイン名) の役割について以下の影響があります。
■ Skype ユーザー との パブリック IM 接続
SRV レコードの登録があれば、コンシュマー向け Skype ユーザーとの 1 対 1 の IM や 1 対 1 の 音声通話が可能です。SRV レコードの登録がない場合は、この機能につきましては利用できません。
■ Skype for Business Online の 組織間のフェデレーション
SRV レコードの登録があれば、外部テナントとのビデオ会議や IM のやり取りも可能です。SRV レコードの登録がない場合は、この機能につきましては利用できません。
■ Skype for Business IM および Outlook on the Web とのプレゼンスの統合
SRV レコードの登録があれば、Outlook on the Web でプレゼンス (在席状態) の表示や 1 対 1 の IM が可能です。
この類のお仕事をしていると様々なトポロジーを Visio で表現する機会があります。
以下に Skype for Business (以下 SfB) および下位互換の製品に関する Visio 図形のリンクを記載します。
– 出典
TITLE : Skype for Business 2015 Visio Stencil
URL : https://gallery.technet.microsoft.com/office/Skype-for-Business-2015-4a8f03dc
TITLE : Lync Visio Stencil 2013 – Custom
URL : https://gallery.technet.microsoft.com/office/Custom-Lync-Stencil-f17a902f
TITLE : Lync Server 2010 Visio Stencil
URL : https://www.microsoft.com/en-us/download/details.aspx?id=20891
ファイルサーバーのアクセス権許可というのは、時にグループに適切なアクセス権を設定したとしても、自分で作成したファイルやフォルダー変更をしたいというユーザーの願いをかなえる為、グループ自体に変更アクセス権を与えてしまう場合があります。
そうすると、悪意のあるグループ内のユーザーは、他者が作成したファイルやフォルダーを勝手に改変してしまうことができてしまいます。
そこで Creator Owner と呼ばれるWindows Build In オブジェクトをアクセス権に設定します。
この権限は、自分自身が作成したファイルのみ変更および削除ができる権限をユーザーに提供します。
つまり、別の作成者が作成したファイルあるいはフォルダーを変更することは出来ません。
知る人ぞ知る、そこそこメジャーなアクセス制御オブジェクトですが、以外に使われてないのが実情なようですので、ブログにしたためた次第です。
Azure AD のIP範囲に大幅な変更が開始されています。
具体的にこの影響を受けるのは、Azure AD との通信をネットワーク機器 (ファイウォール等) で IP 範囲を IP アドレスで絞っている環境です。
以前から公式 IP 範囲リストには入っていたのですが、Microsoft アナウンスでは、この 2 つの IP 範囲が 2018/09/10 までネットワーク機器 (ファイアウォール等) に追加設定されていない場合、Azure AD との接続が中断される可能性があります。
2つの IP レンジは以下の通りです。以前より Azure AD 必須レンジとして公開されていたものです。
20.190.128.0/18
40.126.0.0/18
IP 範囲の変更をトラックしていなかった管理者は直ちにこの変更を行う必要があります。
ただしこれは、上記 2 つの IP範囲に切り替えていくための施策であり、今後 IP アドレスをネットワークセキュリティに対する追加 / 削除の発生が無いようにするための変更となります。
期日はタイトですが、追加する IP レンジは 2 つですので早期の設定をお願いします。
– 出典
TITLE : Azure Active Directory の新着情報
URL : https://docs.microsoft.com/ja-jp/azure/active-directory/fundamentals/whats-new
新規で Active Directory 導入する際、スタートアップ (導入初期時) としては拠点は一か所の場所にドメインコントローラーを配置するため、既定で作成される Default-First-Site-Name で意識せずに構成される企業様が多いようです。
しばらくして、拠点が増え Active Directory サイトを構成する場合、新規作成した AD サイトには、紐づける IP サブネットを定義することで、そのサブネットに参加しているリソース (PC や サーバー) は自分が新しく設けられた AD のサイトに所属していることを認識します。
しかしながら、それ以外のサブネットに所属していたリソースは 「自分の所属しているサイトってどこだ？」 状態になります。
その為、最初の AD サイト (この例だと、Default-First-Site-Name) に、”キャッチオブオール” と呼ばれる IP サブネットを予め初期導入の段階で定義しておきます。
AD サイトの IP サブネットは狭義な範囲設定のほうが優先されますので、その後追加する AD サイトの IP サブネットは安心して追加し、その範囲を享受できるわけです。
~~~ キャッチオブオール IP サブネット ~~~
10.0.0.0/8 (255.0.0.0)
172.16.0.0/12 (255.240.0.0)
192.168.0.0/16 (255.255.0.0)
ご覧いただいた通り、キャッチオブオールとはすべてのプライベートアドレスの範囲を示します。
– 出典
TITLE : Active Directory でキャッチオール サブネットを使用する
URL : https://technet.microsoft.com/ja-jp/library/2009.06.subnets.aspx
Active Directory (以降 AD) の User Principal Name (以降 UPN) は、シンプルな環境ですとドメインの FQDN をサフィックとしたユーザー ログオン ID です。(例:User1@contoso.local)
しかしながら昨今、オンプレミスの AD をマスタとし、SaaS にたいしてプロビジョングをする機会 (例えば Azure AD 連携利用など) が増えています。
この場合、AD のユーザーを SaaS のディレクトリにプロビジョンングする際に UPN を公開されているドメイン名に変更する必要が生じます。
具体的には、 [Active Directory ドメインと信頼関係] スナップイン から公開ドメインの FQDN を UPN サフィックスとして追加することで AD 上のユーザーに公開ドメインを UPN として設定することが可能です。
ユーザーのプロパティで変更するわけですが、数百 / 数千とユーザーがいる場合、一括で設定変更したいというのが人の性というものです。
ここでは、振り返りを含めて、 PowerShell による変更手順を記載します。
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
Import-Module ActiveDirectory
$oldSuffix = “contoso.local”
$newSuffix = “contoso.com”
$ou = “DC=contoso,DC=local”
$server = “DC01”
Get-ADUser -SearchBase $ou -filter * | ForEach-Object {
$newUpn = $_.UserPrincipalName.Replace($oldSuffix,$newSuffix)
$_ | Set-ADUser -server $server -UserPrincipalName $newUpn
}
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
– 出典
TITLE : Step-By-Step: Changing The UPN Suffix For An Entire Domain Via PowerShell
URL : https://blogs.technet.microsoft.com/canitpro/2015/07/07/step-by-step-changing-the-upn-suffix-for-an-entire-domain-via-powershell/
オンプレとクラウドとその狭間で 
コメントを投稿するにはログインしてください。