Attn! Always use a VPN when RSSing!
Your IP adress is . Country:
Your ISP blocks content and issues fines based on your location. Hide your IP address with a VPN!
Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


Channel Description:

Resources for IT Professionals

older | 1 | .... | 815 | 816 | (Page 817) | 818 | 819 | .... | 889 | newer

    0 0

    问题描述

    ===========

    用户来源于本地活动目录,通过DirSync tool或AADSync tool同步到Office 365。给用户分配了Skype for Business Online的许可之后,Skype for Business Online用户账号无法生成,在Skype for Business Online用户列表里面,没有此用户。最终用户也无法登录Skype for Business.

    问题分析

    ===========

    1. 经过观察,我们发现出问题的用户时那些曾经在本地Lync Server/SfB服务器上启用过SfB账号,后来被删除了SfB账号,现在想在Skype for Business Online上为此用户启用Skype for Business Online账号。

    2. 检查此用户的SfB相关的属性值,因此用户在本地SfB服务器上被删除,因此所有SfB相关的属性应该是空置。但我们发现msRTCSIP-DeploymentLocator有一个残留的SRV:值。因此此信息被同步到Office 365之后,Skype for Business Online无法正确读取或判断此属性值,导致无法生成Skype for Business Online账号。

    cid:image003.png@01D110FB.CFE852C0

    问题解决:

    ===========

    1. 把此属性值置空。

    2. 把账号的Skype for Business Online license取消掉,然后再重新分配Skype for Business Online license。

    cid:image004.png@01D110FB.CFE852C0

    在测试环境中,msRTCSIP-DeploymentLocator清空,Skype for Business Online license取消再重新分配之后,用户在Skype for Business Online上被正常启用了:

    cid:image005.png@01D110FB.CFE852C0

    Xixi Huang

    微软合作伙伴技术顾问


    0 0

    本文介绍了以及测试过程。 如果您有 500 多个要迁移的用户或 SharePoint 迁移的数据量大,则最好使用Office 365 合作伙伴。

    源租户Tenant 1:

    Hxx.partner.onmschina.cn

    Huangxixi.com.cn

    目标租户Tenant 2

    hx608.onmicrosoft.com

    目标:把tenant1上的邮箱数据以及域名huangxixi.com.cn迁移到tenant 2上。

    第一部分:准备阶段

    1. 测试账号的准备

    确认huangxixi.com.cn在tenant1上是可以正常使用。Huangxixi.com.cn域名已经绑定到tenant1,并且相关DNS记录已创建好。

    clip_image001

    在tenant1上准备测试用户, 创建3个测试用户账号。

    clip_image002

    测试账号的连接性。

    测试Outlook:

    clip_image003

    测试OWA:

    clip_image004

    测试Lync:

    clip_image005

    Tenant1的测试账号已经准备好。接下来我们就开始做迁移的准备工作以及迁移。

    2. 目标租户上的迁移准备:

    确保目标Tenant 2有足够的license:

    clip_image006

    在target tenant中,创建user object.首先,我们可以批量从source tenant中导出用户信息。可以使用PowerShell,也可以使用Exchange Online向导。在这边,我直接在Exchange Online控制面板中来做。

    另外,在此只测试用户,暂时不测试联系人等其他对象。

    clip_image007

    选择需要导出的属性值:

    clip_image008

    把不需要的测试的账号删除掉,只保留需要测试的3个测试账号:

    clip_image009

    把后缀更改为hx608.onmicrosoft.com

    clip_image010

    然后我们对照sample CSV file给出的模板,修改CSV文件。在实际的执行中,我们可能需要反复编辑CSV,修改里面的参数或格式让它能够通过向导的验证。

    clip_image011

    此测试环境中,我们只保留user name, first name, last name, display name.其中user name和display name不能为空置。

    clip_image012

    clip_image013

    clip_image014

    clip_image015

    clip_image016

    clip_image017

    警告说明,此环境内,已经有用户使用了qitao@hx608.onmicrosoft.com这个地址,因此无法创建成功。因此,在实际的环境中,我们要确保用户的alias都是独一无二的。

    接下来,然后验证这些新用户的连接性。

    NOTE: 在生产环境中,我们需要把这些新账号的密码分发给用户。

    登录正常:

    clip_image018

    邮件接收正常:

    clip_image019

    3. 域的准备:

    把huangxixi.com.cn尝试加到Tenant上。

    clip_image020

    clip_image021

    我们先不要验证,因为域名还在被tenant1使用,验证会失败。

    准备工作已就绪,接下来我们邮件的迁移。

    第二部分邮件的迁移:

    注意:此阶段用户依然需要使用源Tenant的账号进行访问。

    接下来,我们来准备邮箱内容的迁移,可以使用三方迁移工具,也可以使用IMAP迁移。这边,我们直接使用IMAP迁移方法。

    我们先只尝试一个账号:

    clip_image022

    clip_image023

    clip_image024

    clip_image025

    clip_image026

    迁移成功,接下来,我们再迁移另外两个用户的邮件内容。

    clip_image027

    clip_image028

    迁移成功,来查看一下迁移的数据,先来查看qitao@hx608.onmicrosoft.com

    这三封邮件都是来自qitao@huangxixi.com.cn邮箱,说明迁移成功。

    clip_image029

    Eltarish的账号:elt@hx608.onmicrosoft.com

    clip_image030

    Ethan的账号:ethan@hx608.onmicrosoft.com

    clip_image031

    注意:IMAP迁移至迁移邮件内容,不迁移日历和联系人。另外,此方法需要收集每个用户的密码。

    第三部分域名的迁移:

    邮件内容迁移完成之后,修改MX记录的TTL值。当前此测试环境已经把TTL更改到了最小值,10分钟。

    clip_image032

    如果source tenant使用了directory sync,我们现在需要把directory sync禁用掉。此操作后台同步需要24小时完成。

    接下来,就开始域名的正式的迁移。首先,把MX 记录更改为阻止入站的邮件流 。

    在这之前,用户都能正常访问和发送邮件,一旦把MX记录更改,用户的邮件流就会断掉。之所以我们先做IMAP邮件的迁移,再迁移域名是因为整个迁移域名的过程会导致此域名访问的邮件服务的中断。而邮件内容数据量比较大,迁移可能需要花的时间比较长。因此,我们先做邮件内容的迁移,同时在这个比较长的周期内依然能保证用户的访问和邮件功能。(IMAP迁移不会把邮件从源邮箱中删除掉)。

    因为一旦更改MX记录后,用户@huangxixi.com.cn的邮件流会中断,因此,我们应该尽可能做好准备工作以缩短域名迁移的时间周期。

    把MX 记录更改为阻止入站的邮件流:

    把huangxixi.com.cn的MX记录更改为不可到达。 即"unreachable.example.com"。Internet 邮件服务器尝试把新邮件放在queue里,并在24小时内从重新发送。使用此方法,某些电子邮件可能会根据服务器信息返回电子邮件的未送达报告 (NDR)。

    或者,我们可以使用三方的MX 记录备份服务。此类三方服务会帮忙把邮件放在queue里保持几天或几个星期,一旦迁移完成,三方服务可以直接把邮件发送到新的Office 365 tenant.

    在这个测试环境中,我们直接把MX记录更改为不可到达。

    clip_image033

    因为此环境的MX记录TTL值为10分钟,为了确保在这个10分钟之内收到的邮件依然可以通过IMAP迁移被同步到Tenant2的邮箱,我们在10分钟之后,确保MX记录新值已生效后,再删除IMAP迁移。

    clip_image034

    删除IMAP迁移操作后,我们再把source tenant中所有的@huangxixi.com.cn地址给删除掉。一旦删除掉了之后,用户就不能访问服务,因此在这之前,指导终端用户把日历和联系人备份好,因为IMAP迁移不包括日历和联系人。

    ------------

    复位到初始域 (@hxx.partner.onmschina.cn) 对Office 365源邮箱的默认电子邮件地址。

    重置默认的电子邮件地址的所有通讯组列表、会议室以及资源源组织中的初始域 (hxx.partner.onmschina.cn)。

    从仍在使用 @huangxixi.com.cn 的用户对象中删除所有辅助的电子邮件 (代理地址)。

    如果您使用此域名已设置SharePoint Online公共网站,首先必须返回到初始域设置网站的 URL,比如@hxx.partner.onmschina.cn。

    使用Skype for Business Online管理中心删除Lync许可证,这将删除连接到huangxixi.com.cn的Skype for Business Sip 地址。

    在Office 365-域管理面板,把hxx.partner.onmschina.cn设置成默认的域。

    使用 Windows PowerShell 命令Get-MsolUser –DomainName huangxixi.com.cn来检索所有仍然使用域和阻止删除的对象的列表。

    --------------

    在确保所有huangxixi.com.cn地址被删除掉之后,我们就可以把huangxixi.com.cn从Office 365 域名列表内删除掉了。

    clip_image035

    clip_image036

    接下来,我们需要在target tenant执行操作:

    在DNS管理控制台中,把huangxixi.com.cn关联到tenant1的TXT地址删除掉。

    到tenant2中验证域名huangxixi.com.cn。

    clip_image037

    根据向导,把在tenant2上的用户的User ID从hx608.onmicrosoft.com更改为huangxixi.com.cn

    clip_image038

    clip_image039

    clip_image040

    这边我们就不添加新用户。

    根据向导,更改DNS记录。

    注意:如果是全球版Office 365租户到另一个全球版Office 365租户的迁移,就不用更改DNS记录,因为DNS记录值是一样。

    clip_image041

    clip_image042

    clip_image043

    clip_image044

    clip_image045

    第四部分迁移后的验证

    验证tenant2中账号的的登陆以及邮件流。验证成功,用户就可以开始使用此账号了。

    clip_image046

    clip_image047

    clip_image048

    Lync登陆验证:

    clip_image049

    其他需要考虑的事项:

    客户端需要为Tenant2中的新邮箱配置新的Outlook Profile.

    Lync 客户端,您需要迁移完成后手动添加联系人。

    创建沟通计划并开始通知用户即将进行迁移和服务更改。

    Xixi Huang

    微软合作伙伴技术顾问


    0 0

    微軟繼去年推出 Azure IoT Suite 正式版Microsoft Azure Certified for IoT 認證服務,協助企業快速建置物聯網、縮短各種裝置與 Microsoft Azure聯結的時間與成本,並善用 Microsoft Azure 的大數據分析與機器學習服務提供主動且可預測的加值服務;現更推出 Azure IoT Suite 新服務「遠端監控」(remote monitoring)與「預測性維護」(predictive maintenance),以遠端管理、監控與蒐集資訊,全面管理物聯網裝置並將蒐集數據有效轉換成可加值利用的資料,快速加乘物聯網商機!

    Azure IoT Suite 新增「遠端監控」與「預測性維護」服務   完備物聯網解決方案 

    根據市場研究機構Gartner預估,在2020年,全球將有250億連網裝置;另一家知名市場研究機構IDC也預測,全球物聯網市場規模在2020年將達到1.7兆美元!為掌握飛速成長的龐大物聯網商機,企業無不致力發展各類物聯網裝置與應用,搶搭物聯網特快車。然而,佈建物聯網所牽涉的技術繁雜,若無完備的工具輔助,無論是建置或擴充規模都曠日費時,無法即時掌握龐大的訊息流並將之轉化成可深入利用的商業洞見。

    Azure IoT Suite 是專為裝置連上Azure設計的全方位解決方案,能夠快速佈建以節省時間與成本,並具有充足的合作夥伴網絡(裝置製造、系統整合與解決方案供應商),讓Azure IoT Suite成為建構物聯網解決方案的首選。為使物聯網佈建發揮最大效益,微軟再度推出Azure IoT Suite的「遠端監控」與「預測性維護」的全新服務,不但讓Azure IoT Suite部署物聯網的速度與管理裝置能力更上一層樓,企業不需自行建構預測模型,即能在裝置損壞前發出警示並進行系統性修復。

    「微軟在全球有24個 Microsoft Azure 地區,所有資料中心內的光纖長度總和長達140萬英里(225萬公里)。此外,Microsoft Azure 的成長幅度也是有目共睹,新客戶的成長速度達每月9萬個以上新客戶,使用Azure active directory目錄服務的使用者超過5億人,Microsoft Azure 每月所傳達的訊息量更達1.5兆則。」微軟全球物聯網產品行銷總監李承杰(Jerry Lee)表示,「台灣的硬體實力堅強並具有完整的供應鏈,非常有潛力作為物聯網發展的核心戰略中心,微軟一直持續關注並協助台灣物聯網的發展,例如去年10月底微軟與經濟部簽署物聯網產業發展中心合作備忘錄,串連近30家台灣來自產、官、學界的夥伴共同合作,即是最好的例子。除促進合作外,微軟也透過推出如Microsoft Azure Certified for IoT認證服務,偕同裝置製造合作夥伴,一同為企業降低進入物聯網的技術門檻與時間成本,以堅強的物聯網生態系為企業加速佈局物聯網無限商機!」

    Azure IoT Suite 佈局物聯網 企業如虎添翼

    Azure IoT Suite 的設計初衷即為替客戶在不同的物聯網專案中解決問題,包括連結與管理全球數百萬個物聯網裝置和感測器、吸收巨量資訊並轉換成資料即時處理,也整合後端系統以自動化商業流程。

    Azure IoT Suite 針對常見的平行(horizontal) 物聯網情境進行遠端監控、預測性維護與資產管理。「遠端監控」功能除了可遠端監控並管理物聯網裝置外,還可節省管理成本、了解終端客戶的使用行為與優化產品和功能,或是為終端客戶提供預防式服務。「預測性維護」則是以預先設定解決方案將資料以儀表板(Dashboard)與視覺化模式呈現,以協助企業預知警示和潛在問題,並在問題發生前即能預測設備需維護的時機並採取行動。

    雲端暨企業平台研發集團物聯網創新中心副總經理葉怡君表示,「微軟對於台灣物聯網發展的挹注展現在與合作夥伴所建立的完整物聯網生態系上,因為我們了解,沒有單一家公司可以滿足所有物聯網應用的需求。因此透過串連裝置、感測器,整合後端系統與Microsoft Azure 技術,完整物聯網佈局計畫,為企業的物聯網投資創造最大效益。」

    台灣微軟雲端與企業平台事業部資深協理李玉秀表示,「Azure IoT Suite 自推出以來,即大受全球夥伴歡迎,主要原因在於其能有效減少企業建置物聯網的時間、成本並可利用機器學習等技術,將數據轉換成可進一步挖掘與分析的商機。」

    攜手 Microsoft Azure Certified for IoT 認證合作夥伴 建立完整生態系

    微軟去年推出 Microsoft Azure Certified for IoT 認證服務,此認證甫推出即有許多產業夥伴提出申請,目前台灣已獲研華科技、凌華科技與新漢科技等物聯網解決方案夥伴率先取得認證,大幅縮短各種裝置與Microsoft Azure聯結的時間與成本,並善用大數據分析與機器學習服務。

    為促進物聯網產業發展,研華科技(Advantech)與微軟共同打造WISE-PaaS物聯網軟體平台服務,目前亦有許多裝置平台支援Microsoft Azure物聯網建置套件。研華科技技術長楊瑞祥強調,「研華科技(Advantech) 已有5個通過Microsoft Azure 認證的物聯網裝置,這些裝置主要專注於工業自動化、交通和物聯網領域的垂直市場,將協助企業快速擴展,也為物聯網解決方案開啟新世代。」

    凌華科技(Adlink)在物聯網雲端運算裝置亦發展多樣的模組與解決方案,凌華科技量測與自動化產品事業處總經理萬世豪表示,「凌華透過基於物聯網科技的『機械監控與故障預測』(Machine Failure Prediction)解決方案,展示對工業設備執行即時與遠端監控,進而對於可能發生的機器故障狀況獲得精確的預測並預先採取行動,降低因機器故障帶來的危害。透過大數據分析的協助,從累積的訊息挖掘出更多的可利用資訊,有效管理設備與採購流程。」

    新漢電腦 (Nexcom) IoT智動化事業群總經理林弘洲表示表示,「新漢致力於提供工業4.0各種產業智能製造解決方案,我們的工業 Gateway NISE50C,通過 Microsoft Azure Certificate for IoT認證,搭載 Windows 10 IoT Core與新漢 IoT Studio,並整合微軟雲端服務Azure  IoT Suite,提供遠端監控與預測維護保養,協助工廠與機械製造商開創工業4.0智慧服務先河。」

    微軟以完備的物聯網生態體系與解決方案 開啟BYOx世代

    微軟物聯網的彈性解決方案支援豐富、開放的生態系,幾乎可整合大多數的裝置開發者平台或生產力APP,也可透過合作夥伴的支援與企業現有資產與系統連結,並提供來自後端作業系統、服務與數據分析的解決方案。無論是剛起步的新創企業或是已擁有龐大資產的大型企業,微軟物聯網為BYOx的世代準備完備的生態系多樣的服務。


    0 0

    このポストは、1 月 12 日に投稿された Making R the Enterprise Standard for Cross-Platform Analytics, Both On-Premises and in the Cloud の翻訳です。 今回は、マイクロソフトのデータ グループ担当コーポレート バイス プレジデントの Joseph Sirosh の記事をご紹介します。 マイクロソフトは 1 年ほど前に、R の商用ソフトウェア/サービスの大手プロバイダーである Revolution Analytics を買収することを決定しました (英語) 。R は統計計算や予測分析において世界で最も広く使用されているプログラム言語です。そのころマイクロソフトは、R と Revolution のテクノロジをデータベースやビッグ データ、ビジネス インテリジェンスといったさまざまなマイクロソフト サービスに組み込み、そのメリットをオンプレミスや Azure クラウド、新たなタイプのプラットフォームを使用するユーザーや学生に届けようと 取り組んでいました (英語) 。 以来私たちは...(read more)

    0 0

     The ModernBiz Technical Series provides training, demonstrations, and hands-on instruction on how to use the latest Microsoft technologies to deliver solutions to small and midsize organizations. See the latest training in September through to December 2015.

    ...(read more)

    0 0

    Am 12. Januar 2016 endete der Support für Windows 8 durch Microsoft. Das bedeutet für alle Nutzer, dass es ab diesem Zeitpunkt keine Sicherheits-Updates, Aktualisierungen und keinen technischen Support mehr für diese Windows-Version durch Microsoft geben wird. Kunden mit Windows 8 erhalten weiterhin den vollen Support durch Microsoft, indem sie ein Update auf Windows 8.1 durchführen.

    Die Richtlinien zum Lebenszyklus des Windows 8-Supports wurden bereits im Jahr 2014 veröffentlicht: Mit der generellen Verfügbarkeit von Windows 8.1 hatten Windows 8-Kunden zwei Jahre, um ein Update auf Windows 8.1 durchzuführen und damit weiterhin Support durch Microsoft zu erhalten. Nach dem Update auf Windows 8.1 bleiben die Richtlinien zum Ablauf des Supports unverändert: der grundlegende Support läuft bis zum 9. Januar 2018, während der erweiterte Support von Windows 8.1 am 10. Januar 2023 endet. Weitere Informationen zum Lebenszyklus der unterschiedlichen Windows Versionen stehen unter http://windows.microsoft.com/de-de/windows/lifecycle bereit. Mehr Details zur Microsoft Support-Richtlinie für Windows gibt es in diesem FAQ.

    Microsoft empfiehlt Windows 8-Nutzern den Umstieg auf das modernste Betriebssystem: Windows 10 bietet Privat- wie Unternehmenskunden eine einheitliche Plattform für alle Geräte, die höchste Standards an Sicherheit und Verwaltbarkeit erfüllt. Interessierte Kunden finden alle Informationen zum Umstieg auf Windows 10 unter https://www.microsoft.com/de-de/windows/windows-10-upgrade.

     

     

    Ein Beitrag von Irene Nadler (@irenenadler)
    Communications Manager Devices und Services bei Microsoft Deutschland

    - - - -

    Über die Autorin


    Irene Nadler arbeitet bei Microsoft im Bereich Presse und Öffentlichkeitsarbeit und betreut die Themen Windows, Surface und Windows Phone. Mit Windows ist sie schon seit Windows 95 gut bekannt. In ihrer Freizeit stehen Kultur und Fußball ganz oben auf der Liste.

     


    0 0

    微軟攜手研華、凌華與新漢以 Azure IoT Suite 串聯物聯網大未來

    Azure IoT Suite 推出「遠端監控」與「預測性維護」全面掌握物聯網裝置

      (2016年1月14日,台北) 微軟繼去年推出 Azure IoT Suite 正式版與 Microsoft Azure Certified for IoT 認證服務,協助企業快速建置物聯網、縮短各種裝置與 Microsoft Azure 聯結的時間與成本,並善用 Microsoft Azure 的大數據分析與機器學習服務提供主動且可預測的加值服務;現更推出  Azure IoT Suite 新服務「遠端監控」(remote monitoring)與「預測性維護」(predictive maintenance),以遠端管理、監控與蒐集資訊,全面管理物聯網裝置並將蒐集數據有效轉換成可加值利用的資料,快速加乘物聯網商機!

    Azure IoT Suite 新增「遠端監控」與「預測性維護」服務   完備物聯網解決方案 

      根據市場研究機構 Gartner 預估,在 2020 年,全球將有 250 億連網裝置;另一家知名市場研究機構 IDC也預測,全球物聯網市場規模在 2020 年將達到1.7兆美元!為掌握飛速成長的龐大物聯網商機,企業無不致力發展各類物聯網裝置與應用,搶搭物聯網特快車。然而,佈建物聯網所牽涉的技術繁雜,若無完備的工具輔助,無論是建置或擴充規模都曠日費時,無法即時掌握龐大的訊息流並將之轉化成可深入利用的商業洞見。

      Azure IoT Suite 是專為裝置連上 Azure 設計的全方位解決方案,能夠快速佈建以節省時間與成本,並具有充足的合作夥伴網絡(裝置製造、系統整合與解決方案供應商),讓Azure IoT Suite 成為建構物聯網解決方案的首選。為使物聯網佈建發揮最大效益,微軟再度推出Azure IoT Suite的「遠端監控」與「預測性維護」的全新服務,不但讓Azure IoT Suite 部署物聯網的速度與管理裝置能力更上一層樓,企業不需自行建構預測模型,即能在裝置損壞前發出警示並進行系統性修復。

      「微軟在全球有 24 個 Microsoft Azure 地區,所有資料中心內的光纖長度總和長達 140 萬英里(225萬公里)。此外,Microsoft Azure 的成長幅度也是有目共睹,新客戶的成長速度達每月 9 萬個以上新客戶,使用 Azure active directory 目錄服務的使用者超過5億人,Microsoft Azure 每月所傳達的訊息量更達1.5兆則。」微軟全球物聯網產品行銷總監李承杰(Jerry Lee)表示,「台灣的硬體實力堅強並具有完整的供應鏈,非常有潛力作為物聯網發展的核心戰略中心,微軟一直持續關注並協助台灣物聯網的發展,例如去年10月底微軟與經濟部簽署物聯網產業發展中心合作備忘錄,串連近 30 家台灣來自產、官、學界的夥伴共同合作,即是最好的例子。除促進合作外,微軟也透過推出如Microsoft Azure Certified for IoT 認證服務,偕同裝置製造合作夥伴,一同為企業降低進入物聯網的技術門檻與時間成本,以堅強的物聯網生態系為企業加速佈局物聯網無限商機!」

    Azure IoT Suite 佈局物聯網 企業如虎添翼

      Azure IoT Suite 的設計初衷即為替客戶在不同的物聯網專案中解決問題,包括連結與管理全球數百萬個物聯網裝置和感測器、吸收巨量資訊並轉換成資料即時處理,也整合後端系統以自動化商業流程。Azure IoT Suite 針對常見的平行(horizontal) 物聯網情境進行遠端監控、預測性維護與資產管理。「遠端監控」功能除了可遠端監控並管理物聯網裝置外,還可節省管理成本、了解終端客戶的使用行為與優化產品和功能,或是為終端客戶提供預防式服務。「預測性維護」則是以預先設定解決方案將資料以儀表板(Dashboard)與視覺化模式呈現,以協助企業預知警示和潛在問題,並在問題發生前即能預測設備需維護的時機並採取行動。

      雲端暨企業平台研發集團物聯網創新中心副總經理葉怡君表示,「微軟對於台灣物聯網發展的挹注展現在與合作夥伴所建立的完整物聯網生態系上,因為我們了解,沒有單一家公司可以滿足所有物聯網應用的需求。因此透過串連裝置、感測器,整合後端系統與 Microsoft Azure 技術,完整物聯網佈局計畫,為企業的物聯網投資創造最大效益。」

      台灣微軟雲端與企業平台事業部資深協理李玉秀表示,「Azure IoT Suite 自推出以來,即大受全球夥伴歡迎,主要原因在於其能有效減少企業建置物聯網的時間、成本並可利用機器學習等技術,將數據轉換成可進一步挖掘與分析的商機。」

    攜手 Microsoft Azure Certified for IoT 認證合作夥伴 建立完整生態系

      微軟去年推出 Microsoft Azure Certified for IoT 認證服務,此認證甫推出即有許多產業夥伴提出申請,目前台灣已獲研華科技、凌華科技與新漢科技等物聯網解決方案夥伴率先取得認證,大幅縮短各種裝置與Microsoft Azure聯結的時間與成本,並善用大數據分析與機器學習服務。

      為促進物聯網產業發展,研華科技(Advantech) 與微軟共同打造 WISE-PaaS 物聯網軟體平台服務,目前亦有許多裝置平台支援 Microsoft Azure 物聯網建置套件。研華科技技術長楊瑞祥強調,「研華科技 (Advantech) 已有5個通過 Microsoft Azure  認證的物聯網裝置,這些裝置主要專注於工業自動化、交通和物聯網領域的垂直市場,將協助企業快速擴展,也為物聯網解決方案開啟新世代。」

      凌華科技(Adlink)在物聯網雲端運算裝置亦發展多樣的模組與解決方案,凌華科技量測與自動化產品事業處總經理萬世豪表示,「凌華透過基於物聯網科技的『機械監控與故障預測』(Machine Failure Prediction)解決方案,展示對工業設備執行即時與遠端監控,進而對於可能發生的機器故障狀況獲得精確的預測並預先採取行動,降低因機器故障帶來的危害。透過大數據分析的協助,從累積的訊息挖掘出更多的可利用資訊,有效管理設備與採購流程。」

      新漢電腦 (Nexcom) IoT 智動化事業群總經理林弘洲表示表示,「新漢致力於提供工業4.0各種產業智能製造解決方案,我們的工業 Gateway NISE50C,通過 Microsoft Azure Certificate for IoT 認證,搭載 Windows 10 IoT Core 與新漢 IoT Studio,並整合微軟雲端服務 Azure  IoT Suite,提供遠端監控與預測維護保養,協助工廠與機械製造商開創工業4.0智慧服務先河。」

    微軟以完備的物聯網生態體系與解決方案 開啟 BYOx世代

      微軟物聯網的彈性解決方案支援豐富、開放的生態系,幾乎可整合大多數的裝置開發者平台或生產力 APP,也可透過合作夥伴的支援與企業現有資產與系統連結,並提供來自後端作業系統、服務與數據分析的解決方案。無論是剛起步的新創企業或是已擁有龐大資產的大型企業,微軟物聯網為 BYOx 的世代準備完備的生態系多樣的服務。


    0 0

    Back in December, we've been having this ongoing discussion to improve our "medal art" for the TechNet Guru competition.

    1. TechNet Guru 2016 - New Logo and "Badge of Honor" Suggestions Needed! Can you help us decide on design?
    2. Technet Guru 2016: Icon Logo is Go-Go
    3. TechNet Guru Iconography Suggestions

     

    So I'd like to keep it going. Nonki took it on himself to write a program in Small Basic that generates these icons! So cool!

    Not only does Nonki get kudos for creating these images, but he did it using code! Booya! =^)

    Nonki blogged about it on the Small Basic blog:

    And wrote this Wiki article that explains how it was made and gives the variations:

    Nonki's program in Small Basic:

       

    Let's take a look!

    Nonki wrote this Small Basic program for TechNet Guru Iconography.

    The program ID is GGK772.

    Draw your icons for TechNet Guru!

    ============

    Special thanks to XAML guy, Andy, and Nonki for helping us drive this!

     

    Wherever you go... there you Wiki.

       - Ninja Ed


    0 0

    こんにちは。Internet Explorer サポートの太田です。

    1 12 日を持ちまして、IE のサポート ポリシーが変更となりました。

    これに伴い、サポートの終了を迎えたバージョンの IE では、IE11 への移行を促すメッセージが表示されます。

     

     

      日本語(機械翻訳) : Internet Explorer の新しい 「End of Life」 アップグレード通知

      https://support.microsoft.com/ja-jp/kb/3123303

     

      英語 : The new "End of Life" upgrade notification for Internet Explorer

      https://support.microsoft.com/en-us/kb/3123303

     

    今回は、このメッセージに関して FAQ 形式でお答えさせていただければと存じます。

     

     

    Q1. どのタイミングで動作が変更されますか?

    A1. 2016 1 月の更新プログラム適用 (KB3124275) により動作が変更されます。

     

     

    Q2.どのように通知がされますか?

    A2. IE 起動時に IE のダウンロードページが表示されます。

     

     

       Internet Explorer のダウンロード Microsoft Windows

    http://windows.microsoft.com/ja-jp/internet-explorer/download-ie

     

     

    Q3. どのようなタイミングで通知がされますか?

    A3. IE を起動したタイミングで表示されます。

    一度表示された後は 72 時間経過後に IE 新たに起動した場合に表示されます。

    (このため、起動したままの IE では 72 時間経過しても表示はされません。)

     

     

    Q4. 通知以外に影響はありますか?

    A4. 通知以外には影響はございません。

     

     

    Q5. 通知されるバージョンは?

    A5. 32 bit 版 64 bit 版問わず、以下のバージョンで表示されます。

    Windows 7 SP1 IE8, IE9, IE10

    Windows Server 2008 R2 SP1 IE8, IE9, IE10

     

      また、同様に 32 bit 版 64 bit 版問わず、以下のバージョンでは表示されません。

    Windows Vista, Windows Server 2008  IE7, IE8

    Windows 8 , Windows Server 2012 R2 の IE10
     

      

    Q6. 通知を無効にすることはできますか?

    A6. 技術文書にあるレジストリを設定することで可能です。

     

    32 bit OS の場合

    キー : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION

    名前 : iexplore.exe (REG_DWORD)

    : 1

     

    64 bit OS の場合、以下も併せて設定をします

    キー : HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_DISABLE_IE11_SECURITY_EOL_NOTIFICATION

    名前 : iexplore.exe (REG_DWORD)

    : 1

     

     

    Q7. 無効化のレジストリをグループ ポリシーで配布することはできますか?

    A7. 可能です。英語の文献で恐縮ですが、以下を紹介させていただきます。

     

      How to implement the End of Life Feature Control Key outlined in KB3123303 using Group Policy?

      http://blogs.msdn.com/b/askie/archive/2015/12/17/how-to-implement-the-end-of-life-feature-control-key-outlined-in-kb3123303-using-group-policy.aspx

      

     

    Q8. 無効化のレジストリを 1 月の更新プログラム適用前に設定できますか?

    A8. 可能です。

    更新プログラムのインストールなどでレジストリが消えることはございません。

    また 1 月の更新適用前にレジストリを設定しても IE の動作に影響はございません。

     

     

    何かあれば適時更新させていただきます。

    よろしくお願いします。


    0 0

    17 Künstler, 17 Städte, 12 Länder und fünf Wochen: Street-Art Künstler aus der ganzen Welt haben in den vergangenen Monaten kreative Projekte unter dem Motto „Designed on Surface“ verwirklicht. In Deutschland waren gleich zwei Artists am Werk: Die Künstlerin Andrea Wan gestaltete ein Fenster der Digital Eatery bei Microsoft Berlin im Comic-Stil und Illustrator Andreas Preis sprühte einen blau-rotbraunen Wolf auf eine Fassade in München.

    Um die Entwürfe der „Designed on Surface“-Kunstwerke zu zeichnen, hatten die Künstler ein Surface Pro 4 oder Surface Book im Einsatz. Auf den mobilen und gleichzeitig leistungsstarken Windows 10-Devices wurde also ganz flexibel dort gezeichnet und geplant, wo Inspiration und Kreativität am besten harmonierten. „Es fühlt sich an wie traditionelles Malen und Zeichnen, hat aber alle Vorteile der digitalen Arbeit: Präzision, Mobilität und jederzeitige Verfügbarkeit aller Arbeiten auf nur einem Gerät. Wenn man so viel unterwegs ist wie ich, ist das sehr praktisch“, hebt die Schöpferin des Berliner Kunstwerks, Andrea Wan, die intuitive Bedienung mit dem Surface Pen und das mobile Arbeiten auf dem Surface hervor. Ihr schwarz-weißes Bild auf einer Fensterscheibe der Digital Eatery bei Microsoft Berlin kombiniert den traditionellen Comic-Stil mit der Ästhetik einer Tuschezeichnung.


    Die Motive von Andreas Preis zeichnen sich durch ein hohes Detailreichtum aus. Viele parallele Linien sorgen in den Zeichnungen für einen Flechtwerk-Effekt, der seinen Tierbildern einen einzigartigen Stil verleiht. Für das „Designed on Surface“-Projekt hat er in München einen überdimensionalen Wolf auf Beton gesprüht und gemalt. Warum Surface und Adobe Photoshop mittlerweile unverzichtbar für seine Arbeit sind, erklärt er so: „Ohne Surface würde ich definitiv langsamer arbeiten, da man analog so viel vorsichtiger zeichnen muss, um Fehler zu vermeiden. Das Surface ist die perfekte Übersetzung des normalen Zeichnens auf Papier ins Digitale. Ich kann damit ideal kolorieren, in Photoshop fühlt es sich an, als würde man nur noch ausmalen.“


    Erkennen kann man alle „Designed On Surface“-Kunstwerke an einem Rahmen im typischen Windows-Blau. Den ausgewählten Orten in den Städten liegt jeweils eine ganz besondere Stimmung zugrunde, die von den internationalen Künstlern eingefangen und ausgedrückt worden ist. Alle Wandbilder des Projekts können auf der Surface Art Landing Page bestaunt werden. Auf dem Microsoft Devices Blog werden in den nächsten Wochen einzelne Künstler in einem wöchentlichen Portrait vorgestellt.

     

     

     

     

    Ein Beitrag von Irene Nadler (@irenenadler)
    Communications Manager Devices und Services bei Microsoft Deutschland

    - - - -

    Über die Autorin


    Irene Nadler arbeitet bei Microsoft im Bereich Presse und Öffentlichkeitsarbeit und betreut die Themen Windows, Surface und Windows Phone. Mit Windows ist sie schon seit Windows 95 gut bekannt. In ihrer Freizeit stehen Kultur und Fußball ganz oben auf der Liste.


    0 0
  • 01/14/16--05:00: Blast from the Past
  • Hey All, One of my customers has a MOSS 2007 farm and we started having some problems with User Profile Sync between the Service and the Content Database. This is not a new issue in anyway at all but, and the reason I'm writing this post is more for nostalgia as I found a post that I wrote many years ago before I was a PFE. I was a member of the PSS team in Fargo. So check out my really old work here http://blogs.msdn.com/b/spfargo/archive/2009/02/13/guidance-user-info-synch-in-moss...(read more)

    0 0

    By Ian Woodgate, managing director of PointBeyond Limited, a UK based SI helping numerous customers to get the most from Power BI.

    Power BI has rapidly established itself as a capable and popular BI platform. However, did you know that the built-in visuals that you use are all open source, that you can develop your own, and that there is an active community creating and sharing new ones?

    The Microsoft visuals are all built on standards such as HTML5 and CSS3. Not only that, they leverage D3.js– an open source JavaScript library for manipulating documents based on data. It’s worth taking a quick look at the D3 websiteto get a feel for what can be achieved with these technologies.

    What open sourcing of Power BI means

    The open sourcing of visuals and the use of open standards is a very shrewd move on the part of Microsoft. What is the impact of this?

    • Power BI works on a wide range of browsers and devices
    • If you need a specific visual you can easily get it built, and the code of Microsoft’s own visuals is available as a starting point
    • There is a gallery of Microsoft and community developed custom visuals that can freely be downloaded and used
    • We can expect to see an explosion of community developed visuals that are readily available to share
    • There will likely soon be a visual in Power BI to cover most common business scenarios, and probably a fair number of the less common ones

    Potential challenges

    Challenges may also arise of course – such as ensuring custom visuals remain compatible with the rapidly evolving Power BI platform, selecting the best visuals given a large choice (think choosing an app in an app store), and ensuring that only high quality visualisations are shared and used.

    Custom visuals

    The custom visuals available at the time of writing are shown below:

    The latest list can be found on the Power BI website

    Using custom visuals

    Making use of a custom visual is pretty straightforward. This video shows you how:

    (Please visit the site to view this video)

    In the video, I have imported the custom visuals into the Power BI desktop, and placed them into pages of a report. Once this is done the report can be published to the Power BI Servicein the normal way. Equally, it is possible to import custom visuals directly into the Power BI Service in much the same way as shown in the video.

    To find out more about how to write your own custom visuals, or to look at the source code of the existing ones, check out the PowerBI-visuals project on GitHub.


    0 0

    Усовершенствованные комментарии в Visio позволяют обладают следующими свойствами:

    • Комментарии могут привязываться как к фигурам, так и к странице документа.
    • При перемещении или копировании фигуры с комментарием, комментарий «путешествует» вместе с фигурой.
    • Индикатор комментария отображается в верхнем правом углу фигуры или в верхнем левом углу страницы.
    • Посмотреть все комментарии одновременно можно в области Примечания.
    • Помимо написания и чтения комментариев в Visio, эти же действия могут выполняться в веб-браузере, когда схема Visio размещена на сервере SharePoint или в SharePoint Online.

    Чтобы добавить комментарии в схему Visio выполним следующие действия.

    1. Щелкнем правой кнопкой мыши на фигуре и выберем команду Добавить примечание. Visio сбрасывает на страницу индикатор примечания и поле редактирования для текста примечания. Индикатор находится в верхнем правом углу фигуры, поле редактирования отображается над или рядом с ним.

    2. Введем Могут ли люди без программы Visio добавлять комментарии в схему?


    3. Щелкнем правой кнопкой мыши на пустом месте страницы, выберем команду Добавить примечание, введем Отличная сводкаи нажмем клавишу Esc. В верхнем левом углу страницы отображается индикатор комментария.

    4. На вкладке Рецензированиев группе Примечаниящелкнем на кнопке Область примечаний. В открывшейся области Примечанияотображаются все комментарии с этой и всех остальных страниц в схеме.

    Обратите внимание на элементы навигации вверху области Примечания.

    • Кнопки предыдущее/следующее позволяют переходить по комментариям последовательно назад или вперед.
    • Список Фильтр позволяет выбрать категории комментариев, которые нужно посмотреть или отредактировать.

    5. Сохраним изменения.

    Теперь можно загрузить схему на SharePoint и убедиться, что добавленные комментарии будут отображаться и в браузере.

    Функция комментариев в Visio позволяет легко связаться с человеком, который эти комментарии написал. Если навести указатель мыши на имя или фотографию комментатора, появится окошко с его фотографией и четырьмя способами связаться с ним, включая живой чат, если вы и он в настоящее время находитесь онлайн. Три других варианта, помимо электронной почты, требуют использования Skype для бизнеса.

    Для того, чтобы открыть карточку контакта комментатора, нужно нажать на стрелку в нижнем правом углу всплывающего окна. Информация в карточке контакта будет варьироваться в зависимости от того, какие личные данные этот пользователь сделал общедоступными.


    0 0

    Surface 3 タイプ カバー(シアン)発売中止のお知らせ

    平素よりマイクロソフト製品をご愛顧いただき、誠にありがとうございます。

    出荷停止となっていた、Surface 3 タイプ カバー(シアン)につきまして、調達、製造上の理由により発売を行わないこととなりました。

    お客様には、ご迷惑をおかけしますことを、心よりお詫び申し上げます。


    0 0

    本文介绍了如何把Public FolderExchange Server 2010迁移到Exchange Online. 主要包含三个部分:准备工作,公共文件夹的迁移,以及验证迁移是否成功。其中第二部分公共文件夹的迁移包含了8个步骤,描述了迁移的具体流程以及实验截图。

      

    第一部分. 准备工作:

       

    1. Exchange 2010 服务器需要运行 Exchange 2010 SP3 RU8 或更高版本。

    2. Office 365 Exchange Online 中,您必须是”组织管理”角色组的成员。该角色组与订阅 Office 365 Exchange Online 时分配给您的权限不同。

    3. Exchange 2010 中,您必须是”组织管理”或”服务器管理”RBAC 角色组的成员。

    4. 迁移之前,如果组织中有任何公用文件夹大于 2 GB,我们建议删除该文件夹的内容或者将其拆分为多个公用文件夹。

    注意:实际上,如果公共文件夹大于2GB并小于30GB,我们依然可以把此公共文件夹手动添加到迁移的列表中做迁移。 但是最佳实践就是把任何大于2GB的公共文件夹做拆分。

     5. Office 365 Exchange Online 中,您可以创建最多 100 个公用文件夹邮箱。如果您需要超过 100 个公用文件夹邮箱,请联系 Office 365 支持,以请求更多的公用文件夹邮箱,Office 365 支持将会评估您的请求。

    6. 在迁移公用文件夹之前,我们建议您先将所有用户邮箱移动到 Office 365 和 Exchange Online.

    注意:如果是配置Exchange的混合共存环境,那么我们会有一个Exchange的共存阶段,在此阶段内,我们可以在本地Legacy Exchange服务器上创建空的邮箱数据库以及代理邮箱,并在Exchange Online这边把用户的Public Folder配置成远程访问(PublicFoldersEnabled和RemotePublicFolderMailboxes),让迁移到Exchange Online的用户通过代理邮箱远程访问本地的Public Folder.此选项和配置不在本文讨论范围内, 我们会再做另外的单独讨论。

    7. 必须在旧版 Exchange 服务器上启用 Outlook 无处不在,我们可以使用Microsoft Remote Connectivity Analyzer来测试Outlook Anywhere.

    https://testconnectivity.microsoft.com
     

      

     第二部分:迁移公共文件夹

     

    当前本地Exchange Server 2010服务器上的公共文件夹:


     

     

    步骤1下载公用文件夹迁移脚本。将这些脚本保存到您将运行 PowerShell 的本地计算机上。例如,C:\PFScripts

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

     
    步骤2A先决条件: Exchange Server 2010服务器上的先决条件步骤:

     
    1.在旧版 Exchange 服务器上,确保可继续正常路由到将存在于 Office 365 Exchange Online 中的已启用邮件的公用文件夹,直到所有通过 Internet DNS 缓存更新到指向您组织目前所在的 Office 365 Exchange Online DNS。为此,运行以下命令配置一个已知名称的接受域,它将会正确地将电子邮件消息路由到 Office 365 Exchange Online 域。

     New-AcceptedDomain -Name “PublicFolderDestination_78c0b207_5ad2_4fee_8cb9_f373175b3f99” -DomainName Elmohae3.onmicrosoft.com -DomainType InternalRelay

     

    2.如果公用文件夹的名称包含反斜线 \,在迁移发生时将在父公用文件夹中创建该公用文件夹。在迁移之前,我们建议您为名称中包含反斜线的公用文件夹重命名。

    Get-PublicFolderStatistics -ResultSize Unlimited | Where {$_.Name -like “*\*”} | Format-List Name, Identity

     

     如果有返回任何公用文件夹名称包含反斜线,您可以通过使用以下命令对它们进行重命名:

     Set-PublicFolder -Identity <public folder identity> -Name <new public folder name>

      

    3.确保之前没有成功迁移的记录。如果存在,则需要将该值设置为 $false。如果该值设置为 $true,则迁移请求将失败。

      

    a.下面的示例检查公用文件夹迁移状态。

     Get-OrganizationConfig | Format-List PublicFoldersLockedforMigration, PublicFolderMigrationComplete

     

       

    b.如果 PublicFoldersLockedforMigration PublicFolderMigrationComplete 属性的状态为 $true,请使用下面的命令将此值设置为 $false

     Set-OrganizationConfig -PublicFoldersLockedforMigration:$false -PublicFolderMigrationComplete:$false

     

    注意:在重置这些属性之后,必须等待 Exchange 检测到新设置。这可能需要两个小时才能完成。

    或者我们可以重启Exchange Information Store让设置立即生效。

      4.为在迁移结束时进行验证,我们建议您在旧版 Exchange 服务器上运行以下命令行管理程序命令,以获取当前公用文件夹部署的快照。

    a.运行以下命令以获取原始源文件夹结构的快照。

      Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Legacy_PFStructure.xml、 
     

    b.运行以下命令以获取公用文件夹统计信息(如项目计数、大小和所有者)的快照。

     Get-PublicFolderStatistics -ResultSize Unlimited | Export-CliXML C:\PFMigration\Legacy_PFStatistics.xml

    c.运行以下命令获取权限的快照。

    Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML C:\PFMigration\Legacy_PFPerms.xml

     
     

     保存来自上述命令的信息以便在迁移结束时进行比较。
     

    步骤2B先决条件: Exchange Online中的先决条件步骤:

       

    1.请确保没有现有的公用文件夹迁移请求。如果有,请清除它们,否则您自己的迁移请求将会失败。并非所有情况都需要此步骤;只有在您认为管道中可能存在现有迁移请求时,才需要此步骤。

     现有的迁移请求可以是下列两种类型之一:批处理迁移或串行迁移。用于检测每种类型请求和删除每种类型请求的命令如下所示。

     下面的示例会发现任何现有的串行迁移请求。

     Get-PublicFolderMigrationRequest | Get-PublicFolderMigrationRequestStatistics -IncludeReport | Format-List

    如有发现任何现有的串行迁移请求,删除任何现有的公用文件夹串行迁移请求:

    Get-PublicFolderMigrationRequest | Remove-PublicFolderMigrationRequest -Confirm:$false

    下面的示例会发现任何现有的批处理迁移请求。

    $batch = Get-MigrationBatch | ?{$_.MigrationType.ToString() -eq “PublicFolder”}

    如有发现公用文件夹批处理迁移请求, 删除任何现有的公用文件夹批处理迁移请求:

    $batch | Remove-MigrationBatch -Confirm:$false

    2.确保 Office 365 中不存在任何公用文件夹或公用文件夹邮箱。

    如果您在 Office 365 Exchange Online 中发现了公用文件夹,在删除公用文件夹和公用文件夹邮箱之前必须确定它们为什么存在以及您组织中的哪个人启动了公用文件夹层次结构,这一点至关重要。 

    a. Office 365 Exchange Online PowerShell 中,运行以下命令,检查是否存在任何公用文件夹邮箱。

    Get-Mailbox -PublicFolder 


       

    b.如果该命令没有返回任何公用文件夹邮箱,请继续进行步骤 3:生成 .csv 文件。如果该命令返回了所有公用文件夹邮箱,则运行以下命令,看看是否存在任何公用文件夹:

    Get-PublicFolder

       

    c.如果 Office 365 Exchange Online 中有公用文件夹,则运行以下 Exchange Online PowerShell 命令将其删除。请确保您已保存了 Office 365 中公用文件夹内的任何信息。删除公用文件夹后,公用文件夹中包含的所有信息将永久删除。

     Get-MailPublicFolder | where {$_.EntryId -ne $null}| Disable-MailPublicFolder -Confirm:$false

    Get-PublicFolder -GetChildren \ | Remove-PublicFolder -Recurse -Confirm:$false

     
     

    d.删除公用文件夹之后,运行以下命令删除所有公用文件夹邮箱。

     $hierarchyMailboxGuid = $(Get-OrganizationConfig).RootPublicFolderMailbox.HierarchyMailboxGuid

    Get-Mailbox -PublicFolder:$true | Where-Object {$_.ExchangeGuid -ne $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder -Confirm:$false

    Get-Mailbox -PublicFolder:$true | Where-Object {$_.ExchangeGuid -eq $hierarchyMailboxGuid} | Remove-Mailbox -PublicFolder

     
     

     再次确认是否删除成功:

     

    步骤 3生成 .csv 文件

    1.在旧版 Exchange 服务器上,运行 Export-PublicFolderStatistics.ps1 脚本以创建文件夹名称到文件夹大小的映射文件。此脚本需始终由本地管理员运行。该文件具有两列:”FolderName“和”FolderSize“。”FolderSize“列的值将以字节为单位显示。例如”\PublicFolder01,10000“。

     .\Export-PublicFolderStatistics.ps1  <Folder to size map path> <FQDN of source server>

      FQDN of source server 等于托管公用文件夹层次结构的邮箱服务器的完全限定域名。

      Folder to size map path 等于要用于保存 .csv 文件的网络共享文件夹上的文件名称和路径。主题后面部分中,您将需要使用 Exchange Online PowerShell 来访问此文件。如果您仅指定文件名,则将在本地计算机上的当前 PowerShell 目录中生成文件。

      

       

      

     2.运行 PublicFolderToMailboxMapGenerator.ps1 脚本来创建公用文件夹到邮箱的映射文件。此文件用于计算 Exchange Online 中公用文件夹邮箱的正确数量。

    .\PublicFolderToMailboxMapGenerator.ps1 <Maximum mailbox size in bytes> <Folder to size map path> <Folder to mailbox map path>

    Maximum mailbox size in bytes 等于您要为新公用文件夹邮箱设置的最大大小。在 Exchange Online,公用文件夹邮箱的最大大小为 50 GB。我们建议您将此设置设置为 15 GB,以使每个公用文件夹邮箱都有增长的空间。如果单个公用文件夹超过了 2 GB,该公用文件夹不会添加到 .csv 文件。以下是一些供您选择的解决此问题的方法选项:

     在运行脚本之前,删除公用文件夹内容,将大小减少到 2 GB 2 GB 以下。

    在运行脚本之前,将公用文件夹拆分为多个公用文件夹,每个文件夹为 2 GB 2 GB 以下。

    如果公用文件夹大于 2 GB 但不超过 30 GB,您可以在运行脚本之后将它手动添加到 .csv 文件。该公用文件夹将在 Exchange Online 中创建。

      注意1如果公用文件夹大于 30 GB 并且删除内容或将它拆分为多个公用文件夹都不可行,我们建议您不要将此公用文件夹移动到 Exchange Online。 

    Folder to size map path 等于您在运行 Export-PublicFolderStatistics.ps1 脚本时创建的 .csv 文件的文件路径。

    Folder to mailbox map path 等于通过此步骤创建的文件夹到邮箱 .csv 文件的文件名和路径。如果您仅指定文件名,则将在本地计算机上的当前 PowerShell 目录中生成文件。

     

     
     

      

      注意2因为此测试环境的Public Folder比较小,因此在运行脚本时,我们只设置5GB,刚好本地所有Public Foldersize总和还没有超过5GB。因此此脚本会自动的把所有Public Folder规划放置到第一个Mailbox1中。CSVFolderPath显示\Public Folder的根目录,也就是包含了所有的Folders TargetMailbox就是此脚本帮助我们规划出的Exchange Online公共文件夹邮箱。也就是说,接下来,我们需要在Exchange Online新建的一个名称为Mailbox1的公共文件夹邮箱即可。

      注意3当然,如果我们需要自定义Public FolderExchange Online PF mailbox的放置关系,我们也可以手动编辑此CSV,把指定的Public Folder规划到到指定的Exchange Online PF Mailbox中。 另外,我们也可以对TargetMailbox的名称做自定义修改,只要确保跟在下面的步骤4中我们在Exchange Online新建的Exchange Online PF mailbox的名称匹配即可。

     

    步骤 4 Exchange Online 中创建公用文件夹邮箱

    警告警告:

    创建的公用文件夹邮箱的名称需与映射文件中的”TargetMailbox“的名称匹配。可以在映射文件中编辑”TargetMailbox“名称以符合组织的命名约定。 

    1.运行以下命令,以在 Exchange Online 中创建主公用文件夹邮箱。创建的第一个公用文件夹邮箱会成为主层次结构邮箱。需要在 HoldForMigration 模式下创建第一个公用文件夹邮箱。此外,Exchange 会自动将公用文件夹邮箱从服务层次结构中排除,因此 Exchange Online 用户将无法使用这些公用文件夹。

     New-Mailbox -PublicFolder <Name> -HoldForMigration:$true

     

       

    2.基于 PublicFoldertoMailboxMapGenerator.ps1 脚本生成的 .csv 文件,按需运行以下命令创建其他公用文件夹邮箱。例如,如果您打开 .csv 文件,公用文件夹命名为 Mailbox1Mailbox2 等。如果最后一个公用文件夹命名为 Mailbox13,您将需要创建 13 个公用文件夹邮箱。可以创建的公用文件夹邮箱的最大数为 50

    如果您需要创建几个公用文件夹邮箱,可以编写脚本以便自动执行此进程。此示例将创建 15 个公用文件夹邮箱。

     $numberOfMailboxes = 15;

     For ($index = 2; $index -le $numberOfMailboxes; $index++)

    {

        $PFMailboxName = “Mailbox” + $index

        New-Mailbox -PublicFolder $PFMailboxName

    }

     

    步骤5启动迁移请求

     

    1.在旧版 Exchange 服务器上,运行以下命令,将启用邮件的公用文件夹从本地 Active Directory 同步到 Exchange Online

    Sync-MailPublicFolders.ps1 -Credential (Get-Credential) -CsvSummaryFile:sync_summary.csv

    Credential 是您的 Office 365 用户名和密码。CsvSummaryFile 是您要以 .CSV 格式记录同步操作和错误的文件路径。

    注意:我们建议您先模拟脚本操作,然后再实际运行此脚本(为此,可使用 -WhatIf 参数)。 

    在我们的测试环境中,因为没有启用邮件的公用文件夹,因此跳过此步。

      

    2.在旧版 Exchange 服务器上,获取运行迁移请求所需的以下信息:

     

    a.查找用户帐户的 LegacyExchangeDN,该用户帐户是”公用文件夹管理员”角色的成员。这将是此过程步骤 3 中您所需凭据的同一用户。

    Get-Mailbox <PublicFolder_Administrator_Account> | Select-Object LegacyExchangeDN

     

    b.查找具有公用文件夹数据库的任何邮箱服务器的 LegacyExchangeDN

    Get-ExchangeServer <public folder server> | Select-Object -Expand ExchangeLegacyDN

      

    c.查找 Outlook 无处不在 主机名的 FQDN。如果您有多个 Outlook 无处不在 实例,我们建议您选择最接近迁移终结点的实例或最接近旧版 Exchange 组织中公用文件夹副本的实例。以下命令将找到 Outlook 无处不在 的所有实例:

    Get-OutlookAnywhere | Format-Table Identity,ExternalHostName

    把上面所获取到的3个值记录下来。

      3. Office 365 PowerShell 中,运行以下命令,将前一步骤返回的信息传递到将在迁移请求中使用的变量。

     
     a.将旧版 Exchange 服务器上具有管理权限的用户凭据传递到 $Source_Credential 变量中。Exchange Online 中运行的迁移请求将使用此凭据获取对旧版 Exchange 服务器的访问,以复制内容。

    $Source_Credential = Get-Credential <source_domain\PublicFolder_Administrator_Account>

     

    b.使用步骤 2a 中找到的旧版 Exchange 服务器上迁移用户的 ExchangeLegacyDN,将它传递到变量 $Source_RemoteMailboxLegacyDN 中。

    $Source_RemoteMailboxLegacyDN = “<paste the value here>”

      

    c.使用以上步骤 2b 中找到的公用文件夹服务器的 ExchangeLegacyDN,将它传递到变量 $Source_RemotePublicFolderServerLegacyDN

    $Source_RemotePublicFolderServerLegacyDN = “<paste the value here>”

     
    d.使用以上步骤 2c 中找到的 Outlook 无处不在 的外部主机名,将它传递到变量 $Source_OutlookAnywhereExternalHostName 中。

    $Source_OutlookAnywhereExternalHostName = “<paste the value here>”

     

     

      注意:在运行$Source_Credential = Get-Credential <source_domain\PublicFolder_Administrator_Account>时,会提示输入此本地Exchange管理员的密码 。

     

    4.最后,在 Exchange Online PowerShell 中,运行以下命令,创建迁移请求。

     注意:以下命令行管理程序示例中的身份验证方法必须匹配您的 Outlook 无处不在 设置,否则命令将失败。 

    $PfEndpoint = New-MigrationEndpoint -PublicFolder -Name PublicFolderEndpoint -RPCProxyServer $Source_OutlookAnywhereExternalHostName -Credentials $Source_Credential -SourceMailboxLegacyDN $Source_RemoteMailboxLegacyDN -PublicFolderDatabaseServerLegacyDN $Source_RemotePublicFolderServerLegacyDN -Authentication Basic

    New-MigrationBatch -Name PublicFolderMigrationCSVData (Get-Content <folder_mapping.csv> -Encoding Byte) –SourceEndpoint $PfEndpoint.Identity -NotificationEmails <email addresses for migration notifications>

    其中<folder_mapping.csv> 文件是在步骤 3:生成 .csv 文件中生成的。

    在测试环境中,运行命令时,收到报错说已经有一个相同名称的公共文件夹的迁移批处理存在(收到此报错是因为之前我们在此环境已经做过公共文件迁移的测试), 如果我们用其他名称来创建新的迁移批处理,报错提示说只能有一个公共文件夹的批处理。因此,我们必须要删除掉已有的公共文件夹迁移批处理。

     

     
     

     
     

     删除完成后,再次运行:

     
     

     

    5.使用以下命令开始迁移:

    Start-MigrationBatch PublicFolderMigration

     尽管批处理迁移的启动需要使用命令行管理程序中的 New-MigrationBatch cmdlet,但是迁移的进度和完成情况可在 EAC 中进行查看和管理。因为 New-MigrationBatch cmdlet 可启动每个公用文件夹邮箱的邮箱迁移请求,您可以使用邮箱迁移页查看这些请求的状态。您可以进入邮箱迁移页,通过执行下列操作,创建可以通过电子邮件发送给您的迁移报告:

    1.登录到 Exchange Online 并打开 EAC

    2.转到”邮箱”>“迁移”。

    3.选择您刚刚创建的迁移请求,然后单击”详细信息”窗格中的”查看详细信息”。 
     

     
     

      

     
     


     

    6 步:锁定旧版 Exchange 服务器上的公用文件夹以供最终迁移(需要停机时间)

    在迁移过程中的此步骤之前,用户都可以访问公用文件夹。后续步骤会将用户从旧版公用文件夹中注销,并锁定这些文件夹直到迁移完成最终同步时为止。在此过程中,用户无法访问公用文件夹。此外,发送到启用邮件的公用文件夹的任何邮件都会排队,并且在公用文件夹迁移完成前不会进行传递。

    在旧版 Exchange 服务器中,运行以下命令锁定旧版公用文件夹,以便完成迁移。

    Set-OrganizationConfig -PublicFoldersLockedForMigration:$true

    如果组织具有多个公用文件夹数据库,则需要等到公用文件夹复制完成,才能确保所有公用文件夹数据库都选取了 PublicFoldersLockedForMigration 标志,且用户最近对文件夹进行的任何挂起更改都已在整个组织中进行了融合。这可能需要几个小时。

    在旧版 Exchange 服务器中,运行以下命令,以指示公用文件夹迁移已完成:

    Set-OrganizationConfig -PublicFolderMigrationComplete:$true

     当锁定后,本地的公共文件夹就无法被访问:

     

      

    7 步:完成公用文件夹迁移(需要停机时间)

    若要完成公用文件夹迁移,请运行以下命令:

    Complete-MigrationBatch PublicFolderMigration

     本地的Public Folder刚刚被锁定,可能需要时间同步。在重启本地Exchange Information Store后,再次运行命令。

     

     当您完成迁移时,Exchange 将在旧版 Exchange 服务器与 Exchange 2013 之间执行最终同步。如果最终同步成功,将解除锁定 Exchange 2013 上的公用文件夹,迁移批处理状态将更改为”已完成”。

      

    第8部:测试和解锁公用文件夹迁移

    完成公用文件夹迁移之后,您应该运行以下测试,确保迁移成功。这样便能够在切换使用 Office 365 Exchange Online 公用文件夹之前测试迁移的公用文件夹层次结构。

    1.Office 365 Exchange Online PowerShell 中,指定一些测试邮箱将任何新迁移的公用文件夹邮箱用作默认公用文件夹邮箱。

     Set-Mailbox -Identity <Test User> -DefaultPublicFolderMailbox <Public Folder Mailbox Identity>

       

    2.使用之前步骤中确定的测试用户登录 Outlook 2007 或更新版本,然后执行以下公用文件夹测试:

    查看层次结构。

    检查权限。

    创建和删除公用文件夹。

    在公用文件夹中发布内容以及从中删除内容。

     
     

       

    3.如果在验证时,有遇到任何问题,我们可能需要做回滚迁移。如果公用文件夹的内容和层次结构可接受并按预期方式工作,运行以下 Exchange Online PowerShell 命令,为所有其他用户解锁公用文件夹。

    Get-Mailbox -PublicFolder | Set-Mailbox -PublicFolder -IsExcludedFromServingHierarchy $false

    重要说明:

    完成初始迁移验证后,请勿使用 IsExcludedFromServingHierarchy 参数,因为 Exchange Online 的自动存储管理服务使用此参数。 

     

      4.确认迁移完成后,在 Exchange Online PowerShell 中的命令行管理程序中运行以下命令,确保 Set-OrganizationConfig 上的 PublicFoldersEnabled 参数设置为 Local

     Set-OrganizationConfig -PublicFoldersEnabled Local

     

     

    第三部分: 验证公用文件夹迁移是否成功

     

    在步骤 2:准备迁移中,会指导您在迁移开始之前获取公用文件夹结构、统计信息和权限的快照。以下步骤将帮助您通过在迁移完成后获取这些相同的快照,验证公用文件夹迁移是否成功。然后,您可以比较这两个文件中的数据以验证是否成功。

    1. Exchange Online PowerShell 中,运行以下命令以获取新文件夹结构的快照。

    Get-PublicFolder -Recurse | Export-CliXML C:\PFMigration\Cloud_PFStructure.xml

    2.Exchange Online PowerShell 中,运行以下命令以获取公用文件夹统计信息(如项目计数、大小和所有者)的快照。

    Get-PublicFolderStatistics -ResultSize Unlimited | Export-CliXML C:\PFMigration\Cloud_PFStatistics.xml

     

    3. Exchange Online PowerShell 中,运行以下命令以获取权限的快照。

    Get-PublicFolder -Recurse | Get-PublicFolderClientPermission | Select-Object Identity,User -ExpandProperty AccessRights | Export-CliXML  C:\PFMigration\Cloud_PFPerms.xml

     
     

       

      

     

     

    Xixi Huang
    微软合作伙伴技术顾问


    0 0

    场景:本地用比如 123.com, 且有Exchange 2013邮箱。云端用默认的 onmicrosoft.com的域,没有Exchange Online邮箱,只有Lync Online服务。能否做到会话记录保存到本地?

    1. 本地Exchange:

    Exchange 2013
    TMG 2010发布
    域名:jerrye.msftonlinerepro.com
    通配符证书:*.jerrye.msftonlinerepro.com
    公网记录:mail.jerrye.msftonlinerepro.com
    autodiscover.jerrye.msftonlinerepro.com

    2. Lync Online:

    域名:o365pscsupport.onmicrosoft.com

    3. 本地邮箱账户:

    Yuri@jerrye.msftonlinerepro.com

    4. 本地域添加到Office 365 中。

    5. 本地域,添加了 Lync相关记录,并且指向Office 365:

    6. 将本地用户通过目录同步工具,同步到Office 365上:

    7. 给用户Yuri 授予 Lync Online的许可:

    8. 在Skype for Business admin center 中检查是否 Yuri的Lync Online服务开启:

    9. 使用 Yuri@jerrye.msftonlinerepro.com登陆Lync 客户端:

    10. Yuri, 这个用户成功登陆Lync

    11. 大约过了1,2分钟之后,本地Outlook 出现了 Conversation History文件夹,且用户出现Lync状态变化:

    12. 尝试跟纯云端用户 进行Lync对话,比如 tom@O365pscsupport.onmicrosoft.com

    13. 可以看到对方的忙闲状态,进行Lync聊天

    14. 稍等片刻,就能在Exchange 2013邮箱中的Conversation History 看到历史记录:

    Jerry Ye
    微软合作伙伴技术支持工程师


    0 0
  • 01/14/16--22:40: ADFS (1) – Terminologie
  • 1 Úvod V seriálu se budeme věnovat technologii Active Directory Federation Services. Články budou vycházet jednou měsíčně a v prvním díle se seznámíme s terminologií ADFS. Budeme se držet terminologie společnosti Microsoft, v závorce pak terminologie Shibboleth). 2 Teoretický základ Active Directory Federation Services je implementace protokolu WS-Federation Passive Requestor Profile protokolu (Passive...(read more)

    0 0

    こんにちは。 Exchange サポート チームの山崎です。
    今回は、Office 365 テナント内に SMTP アドレスが重複しているとインプレース電子情報開示を利用した検索結果を PST エクスポート時に失敗する現象と、その対処方法についてご説明します。

    現象について
    Exchange Online において、非アクティブなメールボックスとアクティブなメールボックスでメール アドレスが重複している場合、インプレースの電子情報開示と保持による、PST ファイルへのエクスポートが正常に行えない場合がございます

    例えば、非アクティブなメールボックスとアクティブなメールボックスでメール アドレスが重複している状況として、以下の 3 パターンの状況が考えられます。
    本記事では、それぞれのパターンに当てはまる場合の対処策について説明させていただきます。

    パターン1: 1 つのアクティブなメールボックスと、1 つの非アクティブなメールボックスで メール アドレスが重複の場合
    パターン2: 2 つ以上の非アクティブなメールボックスのみで メール アドレスが重複の場合
    パターン3: 1 つのアクティブなメールボックスと、2 つ以上の非アクティブなメールボックスで重複が発生している場合

    メール アドレスが重複している状況で、インプレースの電子情報開示と保持による PST ファイルのエクスポートを行った時にエラーとなった場合には、例えば以下のエラーが発生します。

    エラー内容
    ----------
    Export failed with error: Export failed with error type: FailedToAutoDiscoverExchangeWebServiceUrl Message: user@domain.com (deleted user)
    ----------
    *補足事項
    上記の現象について、メール アドレスの重複が発生している場合にも正常にエクスポートができるように修正が検討されましたが修正は見送られております。
    インプレース電子情報開示を利用したメールボックスの検索には EWS (Exchange Web Services) を利用しており、現時点の実装において SMTP アドレスの重複が発生した状態では EWS が正しく動作いたしません。
    しかしながら、EWS がインプレース電子情報開示以外の様々な機能で利用されており、修正を行う場合の影響範囲とリスクが非常に大きいことから、結果としては見送りとなりました

    対処方法について
    上記現象の対処を行うには、メール アドレスの重複が発生しない状態にする必要がございます。
    以下に、パターンごとの対処方法を記載しましたので、同様の現象が発生した場合には、以下の手順を参考にメール アドレスの重複を解消し、エクスポート処理を実施ください。

    概要
    ========
    パターン1:
    MBX0、MBX1 は同一の SMTP アドレスを持つメールボックスで、MBX0 がアクティブ メールボックス、MBX1 が非アクティブ メールボックスとします。

    1. 非アクティブ メールボックス MBX1 を別のメールアドレスを持つ MBX1’ として復元します。(手順 A.)
    2. ライセンスを付与し、元の MBX1 と同じインプレース保持の対象に MBX1’ を追加します。(手順 B.)
    3. MBX1’ のメールボックスを削除し、非アクティブ メールボックスにします。同時に、MBX1’ と紐づけられていた Azure AD ユーザーを完全に削除します。(手順 C.)
    4. MBX1 に設定されたインプレース保持の設定を全て削除します。(MBX1 の Azure AD ユーザーが完全に削除されていない場合は、手動で削除します。) (手順 D.)
    ⇒ Office 365 の処理にて MBX1 が非アクティブ メールボックスから削除されます。ただし、即時ではない場合がございます。
    5. MBX0、MBX1’ に対して PST エクスポートを実施してください。 (※1)
    ※1 MBX0 に対する PST エクスポートは MBX1 および MBX2 の削除処理完了まで失敗してしまう可能性がございます。

      

    パターン2:
    MBX1 と MBX2 は同一の SMTP アドレスを持つ非アクティブ メールボックスとします。

    1. 非アクティブ メールボックス MBX1 を別のメールアドレスを持つ MBX1’ として復元します。(手順 A.)
    2. ライセンスを付与し、元の MBX1 と同じインプレース保持の対象に MBX1’ を追加します。(手順 B.)
    3. MBX1’ のメールボックスを削除し、非アクティブ メールボックスにします。同時に、MBX1’ と紐づけられていた Azure AD ユーザーを完全に削除します。(手順 C.)
    4. MBX1 に設定されたインプレース保持の設定を全て削除します。(MBX1 の Azure AD ユーザーが完全に削除されていない場合は、手動で削除します。) (手順 D.)
    ⇒ Office 365 の処理にて MBX1 が非アクティブ メールボックスから削除されます。ただし、即時ではない場合がございます。
    5. MBX2 に対して上記の 1 から 4 の処理をします。(※1、※2)
    6. MBX1’ および MBX2’ に対して PST エクスポートを実施してください。
    ※1 重複している非アクティブ メールボックスが 3 つ以上ある場合も、同様の処理を実施してください。
    ※2 重複しているメールボックスすべてに対してではなく、1 つを除いて対処することでも問題はございません。
    上記例の場合、MBX2 に対する処理は必ずしも必須ではありません。
    ただし、MBX1 の削除が即時でない場合があり、それが起因して MBX2 の PST エクスポート処理が失敗する可能性がございますので、その点を考慮頂き、対処を検討頂ければ幸いです

     

    パターン3:
    MBX0、MBX1、MBX2 は同一の SMTP アドレスを持つメールボックスで、MBX0 がアクティブ メールボックス、MBX1 および MBX2 が非アクティブ メールボックスとします。

    1. 非アクティブ メールボックス MBX1 を別のメールアドレスを持つ MBX1’ として復元します。(手順 A.)
    2. ライセンスを付与し、元の MBX1 と同じインプレース保持の対象に MBX1’ を追加します。(手順 B.)
    3. MBX1’ のメールボックスを削除し、非アクティブ メールボックスにします。同時に、MBX1’ と紐づけられていた Azure AD ユーザーを完全に削除します。(手順 C.)
    4. MBX1 に設定されたインプレース保持の設定を全て削除します。(MBX1 の Azure AD ユーザーが完全に削除されていない場合は、手動で削除します。) (手順 D.)
    ⇒ Office 365 の処理にて MBX1 が非アクティブ メールボックスから削除されます。ただし、即時ではない場合がございます。
    5. MBX2 に対して上記の 1 から 4の処理をします。(※1)
    6. MBX0、MBX1’、MBX2’ に対して PST エクスポートを実施してください。 (※2)
    ※1 重複している非アクティブ メールボックスが 3 つ以上ある場合も、同様の処理を実施してください。
    ※2 MBX0 に対する PST エクスポートは MBX1 および MBX2 の削除処理完了まで失敗してしまう可能性がございます。

      

    詳細手順
    ========
    上記手順概要におけるそれぞれの手順 (手順 A/B/C/D) の詳細について記載いたします。

    手順A: 重複している非アクティブ メールボックスの復元手順
    1. SMTP アドレスが重複しない新規メールボックスを作成し、必要に応じてアーカイブを有効にします。Exchange Online でのメールボックスの作成方法およびアーカイブの有効化は以下を参照ください。

    Title: Exchange Online でユーザー メールボックスを作成する
    URL: https://technet.microsoft.com/ja-jp/library/jj907304(v=exchg.150).aspx

    Title: Exchange Online のアーカイブ メールボックスを有効または無効にする
    URL: https://technet.microsoft.com/ja-jp/library/jj984357(v=exchg.150).aspx

    2. 復元リクエストを実行します。
    手順1 を実行した後、暫く時間をおき、以下のコマンドを実行します。
    * New-Mailbox コマンド実行直後に復元リクエストを実行すると、メールボックスの作成が完全に完了していない場合があり、実行に失敗する場合がございます。その為、数十分おいてから次の処理を実行ください。

    New-MailboxRestoreRequest -Name "<リクエスト名>" -SourceMailbox "<メールアドレス重複メールボックス GUID>" -TargetMailbox "<新規作成したメールボックス GUID>" -AllowLegacyDNMismatch

    アーカイブメールボックスについても復元する場合は以下を実行します。
    New-MailboxRestoreRequest -Name "<リクエスト名>" -SourceMailbox "<メールアドレス重複メールボックスのアーカイブメールボックス GUID>"  -TargetMailbox "<新規作成したメールボックスのアーカイブメールボックス GUID>" -SourceIsArchive -TargetIsArchive -AllowLegacyDNMismatch

    *補足事項1
    メールボックスの GUID は以下のコマンドで確認が可能です。

    コマンド:
    Get-Mailbox <メールボックス名> | FL GUID

    実行例:
    Get-Mailbox MBX0 | FL GUID

    Guid : 50ed1388-5f53-4c31-b650-acdd2ee74a5c

    *補足事項2
    メールボックス復元処理の進捗状況については、以下の通り  Get-MailboxRestoreRequestStatistics コマンドにて出力される PercentComplete を確認します。100 (%) になっている場合は、完了です。

    コマンド:
    Get-MailboxRestoreRequest | % { Get-MailboxRestoreRequestStatistics $_.RequestGuid }

    実行結果の例 :
    Name             StatusDetail TargetAlias                    PercentComplete
    ----             ------------ -----------                    ---------------     
    MBX0            Completed    MBX0-new_2015-12-07-2011-22577 100           
    MBX1            Completed    MBX2-new_2015-12... 100          


    手順 B. 復元したアクティブ メールボックスに対するライセンス付与およびインプレース保持の設定

    1. ライセンスを付与します。
    インプレース保持にてデータを保持するには、Exchange Online Plan 2 以上のライセンスが必要となります。

    1-1. ライセンスの付与を実施する為に、ライセンス名とライセンスの残数を確認します。
    Connect-MsolService コマンドでログインし、以下の Azure AD 管理コマンドを実行します。

    コマンド:
    Get-MsolAccountSku | FL ActiveUnits, ConsumedUnits, AccountSkuId

    実行結果の例:
    ActiveUnits   : 25
    ConsumedUnits : 11
    AccountSkuId  :  contoso:ENTERPRISEPACK

    ※ActiveUnits がライセンスの総数、ConsumedUnits がライセンスの使用数となります。
    ActiveUnits から ConsumedUnits の数を引いた値が付与可能なライセンス残数となります。上記の例の場合は、残りのライセンス数は 14 となります。
    また、AccountSkuId に表示される contoso:ENTERPRISEPACK とは、ライセンス付与時に指定するライセンス名として使用する値です。

    以降の処理にて、新しい SMTP アドレスを持つユーザーとして一時的にライセンスを使用いたしますので、上記のライセンス残数の値をご確認頂けますようお願いいたします。

    1-2. 以下の 3 行のコマンドにて、上記の手順で確認したライセンス名を入力し、それぞれのユーザーに対してライセンス付与を実施します。

    $User = Get-Mailbox "<新規に作成したメールボックス名>" | select ExternalDirectoryObjectId
    Set-MsolUser -ObjectId  $User.ExternalDirectoryObjectId -UsageLocation JP; `
    Set-MsolUserLicense -ObjectId  $User.ExternalDirectoryObjectId -AddLicenses "contoso:ENTERPRISEPACK"

    ※ 上記 3 行目の "contoso:ENTERPRISEPACK" 部分は、お客様の AccountSkuId 名を適宜入力してください。

    1-3. 実施後、念の為もう一度以下のコマンドを実行し、ユーザーの isLicensed プロパティが True になっていることを確認します。
    Get-MsolUser -ObjectId  $User.ExternalDirectoryObjectId | FL IsLicensed

    2. インプレース保持の設定をします
    2-1. 以下のコマンドを実行し、特定のキーワードを UPN に含むユーザーを対象とした新しいインプレース保持を作成します。
    $newSource = Get-Mailbox <新規作成したメールボックス名> | select -ExpandProperty LegacyExchangeDn
    New-MailboxSearch -Name "インプレース保持の名前" -SourceMailboxes $newSource -InPlaceHoldEnabled:$true -EstimateOnly

    2-2. 次に、以下のコマンドを実行し、見積もりの実行を行います。
    Start-MailboxSearch "インプレース保持の名前"
    * クエリーを指定していないことから、警告メッセージのポップアップが出力されますが、そのまま続行ください。
    *上述の手順でインプレース保持を新しく作成するか、既存のインプレース保持の設定に追加しても問題ございません。

    手順 C. 復元したアクティブ メールボックスと関連付けられている Azure AD アカウントの削除
    1. メールボックスと Azure AD アカウントの削除
    以下のコマンドにて、今回作成したユーザーの Azure AD オブジェクトを削除を実行します。
    本コマンドの結果、Azure AD アカウントは削除済みユーザーとなり、メールボックスは非アクティブ メールボックスとなります。

    1-1. 以下のコマンドを実行し、対象の ObjectId 一覧を取得します。
    $User = Get-Mailbox "<新規作成したメールボックス名>" | select ExternalDirectoryObjectId,LegacyExchangeDn

    1-2. 以下のコマンドを実行し、対象の Azure AD アカウントを削除済みのユーザーとします。このコマンドを実行してから数分後に、メールボックスは非アクティブ メールボックスとなります。
    Remove-MsolUser -ObjectId $User.ExternalDirectoryObjectId -Force

    2. Azure AD アカウントの完全削除
    以下のコマンドにて、前記 1. で削除したアカウントの Azure AD アカウントを削除済みのユーザーの状態から完全に削除します。

    2-1. 以下のコマンドを実行し、対象の Azure AD アカウントを削除済みのユーザーから完全に削除します。
    Remove-MsolUser -ObjectId $User.ExternalDirectoryObjectId -Force -RemoveFromRecycleBin

    2-2. 上記コマンドを実施後 10 ~ 20 分程度時間を置いた後に以下のコマンドを実行し、ExternalDirectoryObjectId の値が空となることを確認してください。
    Get-Mailbox -InactiveMailboxOnly -Identity $User.LegacyExchangeDn | FL LegacyExchangeDn,ExternalDirectoryObjectId

    2-3. 一連のコマンドの実施結果として、使用可能なライセンス数が元の状態に戻ったことを確認します。

    コマンド:
    Get-MsolAccountSku | FL ActiveUnits, ConsumedUnits, AccountSkuId

    実行結果の例:
    ActiveUnits   : 25
    ConsumedUnits : 11
    AccountSkuId  :  contoso:ENTERPRISEPACK

    ※ActiveUnits がライセンスの総数、ConsumedUnits がライセンスの使用数となります。ActiveUnits から ConsumedUnits の数を引いた値が付与可能なライセンス残数となります。

    手順 D. 重複している非アクティブ メールボックス (復元の対象としたもの) の監査プロファイル設定の削除
    1. 重複していた非アクティブ メールボックスの完全削除
    前記の手順 A. ~ 手順 C. までの処理にて、重複していた非アクティブ メールボックスのデータを持つ別の SMTP アドレスを持つ非アクティブ メールボックスが作成されております。
    そのため、元の重複している非アクティブ メールボックスを以下の手順にて削除します。

    1-1. 削除対象のメールボックスについて、以下のコマンドを実施し、ExternalDirectoryObjectId の値が空であることを確認してください。

    Get-Mailbox -InactiveMailboxOnly -Identity "<削除対象のメールボックスの LegacyExchangeDn>" | FL Identity,LegacyExchangeDn,IsInactiveMailbox,EmailAddresses,InPlaceHolds,ExternalDirectoryObjectId

    ※ Identity には、一意な値となっております LegacyExchangeDn の値を用いてください。

    1-2. 前記 1-1. の確認手順にて ExternalDirectoryObjectId の値が空でない場合には、Azure AD のオブジェクトが削除済みのユーザーとして残存していることを示しております。以下のコマンドを実施して、Azure AD のオブジェクトを削除済みユーザーから完全に削除してください。

    Remove-MsolUser -ObjectId "<1-1. の結果出力された ExternalDirectoryObjectId>" -Force -RemoveFromRecycleBin

    1-3. 削除対象のメールボックスをインプレース保持から削除します。
    1-3-1. 指定したメールボックスをソースメールボックスのリストから除外します。
    $Sources = Get-MailboxSearch "<インプレース保持の名前>" | select -ExpandProperty Sources
    $LDN = Get-Mailbox -IncludeInactiveMailbox "<メールボックス名>" | select -ExpandProperty LegacyExchangeDN
    $Sources = $Sources | ? {$_ -ne $LDN}

    1-3-2. メンバー情報を更新した後、改めて設定コマンドを実行します。
    Set-MailboxSearch "<インプレース保持の名前>" -SourceMailboxes $Sources

    1-3-3.インプレース保持に設定されているユーザーを表示名で一覧表示します。
    Get-MailboxSearch "<インプレース保持の名前>"  | select -ExpandProperty sourcemailboxes

    ※ 上記操作実施後、非アクティブ メールボックスが実際に削除されるまでに時間がかかる場合がございます。

    2. 重複していた SMTP アドレスの重複が解消されたことの確認
    前記までの手順の結果として、SMTP アドレスの重複が解消されたことを以下のコマンドにて確認してください。1 行目の “[対象メールアドレス]" を重複確認したいメール アドレスに変更して実行ください。

    ---- ここから ----
    $address = “[対象メールアドレス]"
    $temp = "*smtp:" + $address + "*"
    $results = @()
    $results += Get-Mailbox -Identity $address -IncludeInactiveMailbox -ResultSize Unlimited | Where-Object {$_.EmailAddresses -like $temp}
    Write-Host ""
    Write-Host "Email Address :" $address
    Write-Host "Count :" $results.Count
    Write-Host "Details :"
    $results | fl Identity,LegacyExchangeDn,IsInactiveMailbox,EmailAddresses,InPlaceHolds,ExternalDirectoryObjectId
    ---- ここまで ----

    出力結果の "Count :" の数が 1 であれば正常に手順が完了しております。
    また、"Count :" の数が 1 でない場合も、前記 1-3. の処理が完了していない可能性もございますので、その場合にはしばらく時間をおいて確認してください。


    0 0

    こんにちは。Windows プラットフォーム サポート 三浦です。

    今回は、よくあるお問合せの一つである リモート デスクトップ接続時に記録される以下のイベントに関して紹介させてい

    ただきます。

     

     ログの名前:         Microsoft-Windows-TerminalServices-RemoteConnectionManager/Admin

     ソース:           Microsoft-Windows-TerminalServices-RemoteConnectionManager

     日付:            2016/01/12 9:59:35

     イベント ID:       20499

     タスクのカテゴリ:      なし

     レベル:           警告

     キーワード:        

     ユーザー:          NETWORK SERVICE

     コンピューター:       XXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     説明:

     リモート デスクトップ サービスで、サーバー \\XXXXXXXXXXXXXXXXXXXXXXXXXから

     ユーザー XXXXXXXX の ユーザー構成を読み込むのに時間がかかりすぎています

     

    このイベントは、リモートデスクトップ接続時、ドメインコントローラーより、ユーザーの構成情報を読み取る際に一定

    時間かかった際に記録されるイベントです。ログオン処理に時間がかかっていることを示す警告イベントとなりますが、

    Windows Server 2012 R2 では、迅速に処理されていても、必ず記録される不具合となります。

    本イベントが記録されている場合でもログオン遅延が発生しているわけではございませんのでご安心ください。

     

    なお、問題がなくても記録されてしまうという本不具合はWindows Server 2012 R2 以外では本問題は発生せず、

    以下のレジストリを設定することにより、イベントの抑制を行うことが可能です。

     

    対象 : リモートデスクトップ接続先

    レジストリキー : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

    名前 : fQueryUserConfigFromLocalMachine

    種類 : DWORD

    データ : 1

    * 再起動の必要はございません。


    0 0

    Система постоянного повышения квалификации средствами Office 365 для изучения возможностей Office 365, дополнительных сервисов и приложений – несомненное средство для успешного проведения учебного процесса в среде Office 365 учебного заведения. Разбираю в этой статье последовательность создания эффективной системы повышения квалификации.

    ...(read more)

older | 1 | .... | 815 | 816 | (Page 817) | 818 | 819 | .... | 889 | newer