Quantcast
Channel: TechNet Blogs
Viewing all 36188 articles
Browse latest View live

Windows 10: New Tool: SetupDiag tool – Diagnose problems with Win7/Win8.1/Win10 to a Win10 upgrade

$
0
0

Applies to:

  • Windows 7 SP1 to Windows 10 (‘all’ versions)
  • Windows 8.1 to Windows 10 (‘all’ versions)
  • Windows 10 (‘all’ versions) to Windows 10 (‘all’ versions)

A new tool to diagnose problems with Win7/Win8.1/Win10 to a Win10 upgrade.

SetupDiag tool release notes:

https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag#release-notes

SetupDiag tool requirements:

https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag#requirements

SetupDiag tool download location:

https://go.microsoft.com/fwlink/?linkid=870142

SetupDiag tool parameters that can be passed:

https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag#parameters

SetupDiag tool, what does it check for?

https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag#rules

SetupDiag tool, sample output:

https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag#sample-output

For details:

SetupDiag

https://docs.microsoft.com/en-us/windows/deployment/upgrade/setupdiag

Thanks,

Yong (In Irvine, CA.)


AI Technology Assisting Deaf Students

$
0
0

I read a great case study this morning out of New York City's Rochester Institute of Technology which has 1500 dear of hearing impaired students, and are now using Microsoft Translator to provide real time captioning and translation to support the American Sign Language (ASL) translators in the lectures.

Read the entire case study here

I've blogged about this before here and here and also wrote an article about the impact of Artificial Intelligence (AI) more generally in the classrooms for the Interface Magazine that you can read here.

This case study is really timely as I was in a school in Wellington yesterday working with a teacher who has a profoundly deaf student in her class and having the ability to use something like Translator will certainly add another layer of information for the student in the absence of a full time sign language translator.

The conversation in the classroom yesterday, and the case study above, reminds me again of Microsoft's commitment to accessibility and the Seeing AI app is another great example of this that I was able to share with a teacher yesterday who has a blind student in her class:

Microsoft

Joseph Adjei, a first-year deaf student from Ghana loves Microsoft Translator

In my experience, the Microsoft Translator works best if the presenter/speaker is wearing a mic close to their mouth for the most accurate detection of their speech. Using the default in-built mic on a laptop generally has too much ambient noise and can reduce the accuracy and quality of the transcription and consequently the translation as well if this feature is being used.

If you're using this in your classes, I'd love to hear how the experience is going so drop a note in the comments below.

パートナー×マイクロソフト、各種セミナーとお役立ちリソースご紹介【4/6 更新】

$
0
0

マイクロソフトではパートナー様と共催し、様々なセミナーを行っております。

2018年5月25日より、施行されるGDPR (EU 一般データ保護規則) に向けて、今からできる対策セミナーや、Windows 7のEOSに向けての移行に役立つセミナー、データセキュリティを担保したクラウド移行セミナー等、様々なセミナーを全国津々浦々で開催しております。

皆様の「ちょっと知りたい」「困ったな」を解決するお手伝いをさせていただけると思いますので、ぜひお気軽にパートナー×マイクロソフトセミナーへお越しください。

 

★現在開催予定のパートナー×マイクロソフトセミナーの一部をご紹介します!★

ご参加登録はそれぞれのリンクからお願いいたします。

 

<東京開催>

4月12日(木) GDPR施行直前! ご準備本当にお済みですか?セミナー

GDPRに関するリソースはこちらもご参考ください。

 

<名古屋開催>

4月25日(水) グローバル展開 & GDPR 対策、ここがポイント!

 

<大阪開催>

4月26日(木) グローバル展開 & GDPR 対策、ここがポイント!

5月10日(木) クライアント仮想化を活用したWindows 10への移行セミナー

5月16日(水) 働き方改革、始めませんか? ~Box using Microsoft Azureセミナー~

 

<福岡開催>

4月26日(木) Windows7サポート2020年1月終了!どんな影響があるの?教えてセミナー

6月6日(水)   ベリタスソリューションを使ってAzureを活用する体験セミナー

 

 

★ご活用ください!マイクロソフトの法人のお客様/パートナー様向けイベント/セミナー簡単検索★

開催地域や開催時期、対象のMS製品、ソリューション分野やキーワードなどで絞込検索もできます。ぜひ以下のリンクから検索してみてください!

 

▼ 法人のお客様/パートナー様向けイベント/セミナー簡単検索はこちらから

 

 

Elster Testmerker

$
0
0

Hallo Zusammen,

anbei eine Anleitung, um den Testmerker in der Elster XML-Datei in Dynamics 365 for Operations setzen zu können. Somit kann dann eine Elster Testversendung an das Finanzamt gemacht werden.

Viele Grüße

Ihr Microsoft Support Team Deutschland

Dyn365_ElsterTestmerker

Dieses Dokument dient nur zu Informationszwecken. MICROSOFT SCHLIESST FÜR DIE INFORMATIONEN IN DIESEM DOKUMENT JEDE GEWÄHRLEISTUNG AUS, SEI SIE AUSDRÜCKLICH ODER KONKLUDENT.

仮想マシン メトリック (“ホスト”と “Guest”) の違いについて (Windows 編)

$
0
0

こんにちは。Azure サポートチームの佐藤です。
Azure ポータルでは、仮想マシンの概要画面より [メトリック] という機能を選択することで、仮想マシンの監視メトリックを確認することができます。
この仮想マシンの監視メトリックには、メトリック名の頭に [ホスト] ・ [Guest] と記載された 2 つの種類があります。
本記事では、この 2 種類のメトリックの詳細についてご案内します。

本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。

[ホスト] メトリックについて


項目の頭に [ホスト] と記載されたメトリックは、仮想マシンが展開されている物理ホスト サーバー側から取得している値を示します。
こちらは、特段、お客様側での設定を行うことなく Azure ポータルよりご確認いただくことができます。
仮想マシンが展開されているホスト サーバー側から取得している監視メトリックの詳細については、以下の公開情報に記載されておりますので必要に応じてご参照ください。

[参考]
Azure Monitor のサポートされるメトリック - Microsoft.Compute/virtualMachines
※一部、記載のない項目もありますが、公開情報は順次アップデートされる予定です。

[Guest] メトリックについて


項目の頭に [Guest] と記載されたメトリックは、仮想マシン内部のパフォーマンス カウンターから取得している値を示します。
こちらは、Azure ポータルなどから、仮想マシンの診断設定を有効化 (ゲスト レベルの監視を有効化) することで値の取得を行えます。
それぞれの監視メトリックは、仮想マシン内部のパフォーマンス カウンターの値と紐づいており、Azure ポータルでも、パフォーマンス カウンター上で確認できる値の名前が表示されます。

 

各メトリックと紐づくパフォーマンス カウンターの値の詳細は、本ブログの投稿「仮想マシンの監視メトリックの詳細について」内で確認手順をご案内しております。
監視メトリックが何を指しているのか不明な場合には、"パフォーマンス カウンターの値の詳細について" の箇所をご参照のうえご確認ください。

 

また、取得したメトリックは、お客様で指定可能な任意のストレージ アカウント内に保存され、リテンション期間を "0" とすることで、ログを永続的に保持することも可能です。
仮想マシンの診断設定は、Azure ポータルにて、仮想マシンの [診断設定] メニューより、有効 / 無効を切り替えることができますので、必要に応じて機能のご利用をご検討ください。

 

診断設定の有効化

 

診断設定の無効化

 

なお、仮想マシンの診断機能については、以下、本ブログの投稿でも概要をご案内しております。こちらも併せてご参考ください。

 

 

New URL & IP Provisioning Service for Office 365

$
0
0

03 April 2018

Today I've got some excellent news to share around improvements Microsoft have made in the connectivity space for the Office 365 service. This consists of two elements, a preview of a new method to provide the URL & IP requirements for the service which will help our customers manage and automate the requirements, and secondly, as part of this new service, we've added an improved categorization of the URLs required. This second element is designed to help customers optimize traffic which really warrants special treatment, then allowing the rest to go via the standard egress model. This second element is outlined in more detail here.

In this post I'll cover new method for the management of URLs & IPs for the service. Currently, the place to go for connectivity requirements to Office 365 has been our URL & IP page which consists of three elements:

 

  1. The web page itself, for human review of the requirements broken down per service
  2. The XML file which can be used for device configuration
  3. The RSS feed for change notification

     

     

The change cadence we aim for in this space is updates once a month, at the end of the month, with one month's notice and this cadence will continue with the new solution.

We also publish example PAC files via a link from this page to help customers with common splits in traffic handling (All URLs, IP provisioned and non IP provisioned, and ExpressRoutable URLs).

We do have a challenge with this solution however. As the Office 365 service has grown, the number of URLs and IPs required to access the service has obviously increased in line with this growth, also the number of connection options has also increased with the addition of Expressroute. Customers have been reporting to us that they are running into administrative challenges keeping pace with the rate of change in this space and the current solution to provide this data is not meeting their needs as it often requires manual management of the changes.

Another challenge is around how the URLs need to be handled, some have IPs provided, some don't, some live on Microsoft infrastructure, some don't, some are required, some aren't, some can use ExpressRoute for Office 365, some cannot. The XML file just doesn't provide the data in a way which allows customers to deal with these attributes as they require, nor automate or script based on this information.

We have therefore been working in the background to improve how we provide this information to meet our customers' needs moving forward and im pleased to say that we have a new solution in preview as of 2nd April 2018. The official source of this information, and the place to monitor for updates, and provide your much desired feedback is here.

Data is now provided in JSON format and is tagged with various attributes to allow you to script and manage the data as you see fit, some of these attributes are new, such as the 'Optimize', 'Allow', 'Optional' tags plus Expressroute. (More on this in another blog post here)

Benefits for administrators from the Office 365 IP Address and URLs web service and the new categories include:

  • Automation of Office 365 endpoint data and changes publishing
  • System readable data for direct network device integration that is also script friendly
  • Data available in JSON for scripts or CSV format for Excel
  • Includes the first release of new Optimize, Allow, Default categorization of Office 365 endpoints
  • Includes ExpressRoute routable flag for each endpoint
  • Version change notification published alongside the data
  • All provided attributes are supported by owning development teams

We're also working on automated PAC file provisioning based on your requirements.

This new solution is in preview and should not be used for production just yet, rather be used for testing and analysis about how it can help improve how you handle this information moving forward, we will aim to ensure the data is accurate however during the preview.

What we would love however is your feedback on the new solution. Whilst we constantly work with customers to help them connect to the service and thus understand the challenges in this space and have therefore endeavoured to address them in the new solution, we'd love to hear if the solution indeed addresses them for you, or if there are additional requirements you have which the solution does not yet provide.

As noted, the official place for more detail, following the progress of this solution, and providing your feedback is over on the Microsoft Tech Community and we look forward to hearing from as many of you as possible!

Paul

After enabling Out of Office (Automatic) replies, the replies are not being sent out

$
0
0

As noted in the post title, after enabling Out of Office (Automatic) replies, the replies were not being sent out

We found in this case that our issue with the Out Of Office (OOF/Out Of Facitility) not working was due to all of the mailboxes in question having the ForwardingSmtpAddress value set, which is the "Forward my e-mail to" option in the Connected Accounts area in the OWA options/control panel. 

We ran the PowerShell command below to clear this value from all of the affected mailboxes:
Get-Mailbox | Set-Mailbox -ForwardingSmtpAddress $null

Once we cleared this value, the OOF began working. 

As a workaround for the forwarding, there are a few options:

1) Create a Transport Rule (in the Mail Control, Rules section of the Exchange Control Panel) and using the Advanced Options, choose to BCC the messages to another recipient.

2) Use the PowerShell command and set the -ForwardingAddress instead of the -ForwardingSmtpAddress
Set-Mailbox username -ForwardingAddress address@domain.onmicrosoft.com

3) An Inbox rule can be created to do the forward or redirect:
http://help.outlook.com/en-gb/140/ms.exch.ecp.learnredirectto.aspx

#1 and #2 will be invisible to the mailbox owner/user

#2 actually works a little differently than when ForwardingSmtpAddress is set, and does not break the other auto-replies.

After checking these, we found that the OOF still would not work for an admin mailbox that was affected. We found that this was because the admin mailbox is specified as the NDR recipient in the Journaling settings for the organization, which also stops auto-replies and auto-forwards from working, as noted in https://support.microsoft.com/en-us/help/2829319/transport-and-mailbox-rules-in-exchange-online-or-in-on-premises-excha

Field Learnings- Surface System SKU Information

$
0
0

Hi, my name is Scott McArthur and I am a Senior Supportability PM for Surface.  Today’s blog is a discussion on using System SKU to identify specific Surface models.

There are various scenarios where you might need to identify specific Surface models for some type of action.  In the past the SMBIOS variable System Model could be used but sometimes that is not enough to differentiate devices. For example, the new Surface Pro (Model 1796) and Surface Pro with LTE Advanced (Model 1807) have the same System Model, Surface Pro. So, if you wanted to do some type of action only on one of the models, this is where you would need to use the variable System SKU to differentiate between the two.

The following table shows the devices where you need to leverage System SKU:

 Device  Model  System SKU
 Surface 3 WiFi  Surface 3  Surface_3
 Surface 3 LTE AT&T  Surface 3  Surface_3_US1
 Surface 3 LTE Verizon  Surface 3  Surface_3_US2
 Surface 3 LTE North America  Surface 3  Surface_3_NAG
 Surface 3 LTE Outside of North America and Y!mobile in Japan  Surface 3  Surface_3_ROW
 Surface Pro  Surface Pro  Surface_Pro_1796
 Surface Pro with LTE Advanced  Surface Pro  Surface_Pro_1807
 Surface Book 2 13 inch  Surface Book 2  Surface_Book_1832
 Surface Book 2 15 inch  Surface Book 2  Surface_Book_1793

 

You can use the following PowerShell command to pull System SKU:

gwmi -namespace rootwmi -class MS_SystemInformation | select SystemSKU

You can also find the System SKU and System Model for a device in System Information. Just type MSInfo32 in the Start Menu search field.

One example of how you could use this in Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager is part of a Task Sequence WMI Condition.  For example:

  • WMI Namespace –  RootWMI
  • WQL Query –  SELECT * FROM MS_SystemInformation WHERE SystemSKU = "Surface_Pro_1796"

Hope this helps with your Surface Deployments.

This field learnings blog written by Scott McArthur, Senior Supportability Program Manager


In Place Upgrading the SSRS for SCOM

$
0
0

I ran into an odd issue today, doing an in-place upgrade of SQL 2012 SP3 to SQL 2016 in prep for a SCOM upgrade that was worth noting. My customer had separate instances for the DB/DW, and that upgrade was fine. However, when doing an inplace of SSRS, we got the following failure during the SQL upgrade:

image

There isn’t much out there on the matter, other than noting that the SQL installer doesn’t support custom extensions. The problem, as I see it is that when SCOM reporting is installed over SSRS, it does a whole lot of crap to the RSReportServer.config file. In this case, the following lines appear to be the culprit.

image

To fix, we did the following.

1) Locate and backup the RSReportServer.config file

2) Open the original copy with notepad and do a search for <Authentication>. The second <Authentication> tag will take you to place where these extensions are located.

3) Remove the extensions (the entire contents from opening to closing tags). You can leave the open and close tags for <Security> and <Authentication> (note we recycled the report server service as well, but I’m not sure this is necessary). We simply pasted these items into a separate notepad document. We then saved the RSReportServer.config file. This breaks SCOM reporting at this point.

4) Perform an in-place upgrade of the SQL server.

5) Re-add the extensions.  It is worth noting that the RSReportServer.config file moves to another directory during a SQL in place upgrade. You’ll need to find that new file and add the custom extensions back in there.

6) Last, but not least, there are some SCOM related files that get left behind in the old report server bin directory. Copy those files into the new SSRS location. Do not replace anything that’s already there, just copy over the files that are left behind. After this, recycle the SSRS server. This should allow reports to load. SCOM reporting was functional again at this point.

Microsoft инвестирует 5 млрд долларов в Интернет вещей

$
0
0

Компания Microsoft недавно объявила, что в течение следующих четырех лет инвестирует в Интернет вещей 5 миллиардов долларов. Причина проста: цель дать каждому клиенту возможность трансформировать свой бизнес и мир в целом с помощью связанных решений.

Хорошо известно, что решения IoT могут повысить эффективность работы, но компания Microsoft знает, что истинное воздействие выходит далеко за рамки нашей повседневной жизни. Наши клиенты поставляют электроэнергию в школы Африки; создают все условия для пациентов, которых можно полностью излечить; улучшают безопасность работников на рабочих местах и безопасность водителей на дорогах Аляски.

Мы инвестировали в IoT до того, как этот термин был придуман, когда у предприятий были пункты на производственных зданиях и других устройствах, которые были полностью “темными".

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

Инвестиции, которые мы объявляем сегодня, гарантируют, что мы продолжим удовлетворять все потребности наших клиентов как сейчас, так и в будущем.

Читайте подробнее в блоге

System Center Configuration Manager Support Center ツールについて

$
0
0

みなさま、こんにちは。System Center Support Team です。

 

System Center Configuration Manager  (以下、SCCM) をご利用頂いている際に、

以下のようなことを感じたことはありませんでしょうか?

・ クライアントに何が配信されているのか確認したい
・ 各種インベントリで収集している具体的な情報が確認したい
・ SCCM のログが分かりにくい
今回の記事では、そのような時にご活用いただける Support Center ツール をご紹介いたします。

 

Support Center ツールをご利用いただくと、以下のようなことが実施できます。

■クライアントの情報
クライアント ID、ハードウェア ID、エージェントのバージョン、サイトコード、割り当てられた管理ポイント、常駐管理ポイントなど、クライアントの情報を表示することが可能です。

クライアント ポリシー
クライアントに割り当てられたユーザーとコンピュータのポリシーを表示することが可能です。

コンテンツ
キャッシュ フォルダー  (ccmcache) の内容を表示することが可能です。
また、アプリケーションの展開評価サイクルやソフトウェア更新プログラムの展開評価サイクルなどの評価サイクルを実行することが可能です。

インベントリ
インベントリの最終収集時刻の表示やインベントリ情報を表示することが可能です。
また、ハードウェア インベントリ サイクルやソフトウェア インベントリ サイクル などの評価サイクルを実行することが可能です。

トラブルシューティング
あらかじめ定義された一連のトラブルシューティング手順を実行することが可能です。

ログ
収集したログを見やすく表示することが可能です。また、特定文字でフィルタやレコードの塗りつぶしを行うことも可能です。

データ収集
上記タスクの実行結果および Configuration Manager クライアントのレジストリ設定、WMI 情報を収集し、結果を圧縮保存することが可能です。
Support Center ツールは以下の URL にて、ダウンロード頂くことが可能です。
http://www.microsoft.com/en-us/download/details.aspx?id=42645

 

今回はそれぞれのシーンにおいての Support Center ツール の活用方法をご紹介したいと思います。

Topic 1  クライアントに何が配信されているのか確認したい

SCCM を利用した運用が始まるとアプリケーションやソフトウェア更新プログラムの展開を多く実施されると思います。
検証機などは特に展開回数が多く、 「このクライアントには何が展開済みなのか?」「今、何が展開されているのか?」などを疑問に思われるシーンがあるかと存じます。

その際には [Content] をご活用下さい。[Content] タブでは 展開済みのコンテンツの一覧、コンテンツ キャッシュの一覧、展開のモニタリングを行うことが可能となります。

操作
[Content] タブより、見たい対象のオブジェクトを選択し、[Load] を押すだけです。コンテンツ一覧であれば、 [Content] を選択後、[Load] を押してください。

・展開済みのコンテンツの一覧

・コンテンツ キャッシュの一覧

・展開のモニタリング

 

Topic 2  各種インベントリで収集している具体的な情報を確認したい

SCCM は、ハードウェア インベントリやソフトウェア インベントリなど複数のインベントリ機能でハードウェアやソフトウェアに関する様々な情報を収集しております。
実際に SCCM を運用が始まると どの機能で、どのような情報を収集しているのかを確認したい場面に遭遇することもあるかと存じます。

その際には [Inventory] タブをご活用下さい。[Inventory] タブでは 探索データ (DDR)、ハードウェア インベントリ (HINV)、ソフトウェア インベントリ (SINV) などのインベントリ情報を閲覧することが可能です。

操作
[Inventory] タブより、確認したい対象のオブジェクトを選択し、[Load] を押すだけです。定期探索であれば、[DDR] を選択後、[Load] を押してください。

・DDR

>> コンピューターのホスト名、IP アドレス、ドメイン等の情報を閲覧可能です。
・ハードウェアインベントリ

>> ハードウェア インベントリでは各デバイスの OS やハードウェア構成およびインストールされているアプリケーションや更新プログラムなどの詳細情報が閲覧可能です。

 

・ソフトウェア インベントリ

>>ソフトウェア インベントリでは各クライアントの実行プログラム (EXE) や DLL ファイルなどのファイル情報を閲覧することが可能です。

 

Topic 3  SCCM のログがわかりにくい

SCCM では処理を行っているコンポーネント毎にログが出力されます。また、ログ内の情報も多く、分かりにくいです。

その際には [Logs] タブをご活用下さい。[Logs] タブより、確認したい対象のログを開く(複数選択可能)とログの内容を見やすく表示します。

操作
[Logs] タブより、[Open logs] を選択し、見たい対象のログを開きます。

>> 複数のログを一つの画面で開くことが可能なため、複数の情報を効率良く閲覧することが可能です。

 

また、こちらのログ機能は Support Center Log File Viewer (CMLogViewer.exe) を実行すれば、Support Center を開かなくても単体で利用可能です。

操作
[スタート] - [Microsoft System Center 2012 R2] - [Support Center Log File Viewer] を選択します。

 

 

番外編  リモートコンピューターに対しても実行可能!

Support Center ツール はリモートコンピューターに対しても実行することが可能です。 手元にないクライアントの情報を確認する場合においても是非ご活用下さい。

操作
画面左上のホームボタン(▼) を選択し、[Remote Connection] を選択します。[Configuration remote machine connection] 画面から、対象のコンピューター情報およびアカウント情報を入力後、[Apply] を実行することでリモート接続が可能です。

Outlook でメールを保存または送信時に 「クライアントの処理が失敗しました」または「このアイテムを指定されたフォルダーに保存できません。」エラーが発生する問題

$
0
0

日本マイクロソフト Outlook サポート チームです。
本ブログでは、以下の現象発生条件に該当する特定のメールを保存または送信時にエラーが発生し、保存、送信ができない現象についてご説明します。

 

現象発生条件
以下のすべての条件を満たす場合に発生します。

・Windows 版 Outlook を Exchange Server にオンライン モードで接続して利用している環境
・添付ファイルまたは本文に埋め込み画像があり、ファイル名に半角カタカナが利用されている場合
・[下書き] フォルダーに保存したアイテムを開いて操作

 

現象
[下書き] フォルダーに保存されたアイテムを開き、編集後に [保存] または [送信] を実行すると以下のエラーが発生します。

 

「クライアントの処理が失敗しました。」とエラーが表示されます。

 

「このアイテムを指定されたフォルダーに保存できません。フォルダーが削除または移動されたか、またはフォルダーにアクセス権がないことが原因として考えられます。アイテムの既定のフォルダーにコピーを保存しますか?」とエラーが表示されます。

 

原因
Outlook および Exchange Server は、それぞれでメールなどのアイテムの保存、送信時に、アイテム内で使用している文字列から文字コードを決定するための自動判定処理が実装されています。
Outlook で任意に指定および自動判定された文字コードと Exchange Server が自動判定した文字コードが異なる場合、アイテムの文字コードを変換するための書き込み処理が発生しますが、この動作の一連の処理に問題があり、エラーが発生します。

例:
日本語版 Outlook の既定の文字コード設定は日本語 (JIS) ですが、その場合、アイテムに半角カタカナの文字を含む時の既定の文字コードの自動判定はそれぞれ以下となり、文字コードを変換するための書き込み処理が発生します。

  •  Outlook - 日本語 (JIS) Windows コードページ 50220
  •  Exchange Server -日本語 (JIS 1 バイト カタカナ可) Windows コードページ50222

Outlook クライアントは半角カタカナが含まれていても、日本語 (JIS) Windows コードページ 50220 として判定しますが、半角カタカナは日本語 (JIS) Windows コードページ 50220 には含まれていません。
そのため、Exchange Server では、データに半角カタカナが含まれている場合には、コードページの自動検出の際に異なるコードページ処理が動作します。

半角カタカナが含まれている場合でも、アイテムで使用されている他の文字列により別のコードページとして自動判定される場合もあります。

 

対処方法
(1) 一度リッチ テキスト形式に保存する (現象が発生しているメールが HTML 形式の場合)

  1.  [下書き] フォルダーに保存したアイテムを開きます。
  2.  [書式設定]-[リッチ テキスト] をクリックして保存します。
  3.  [HTML] をクリックして HTML 形式に戻します。

 

(2) 既定の文字コードを Unicode (UTF-8) にする

  1.  [ファイル]-[オプション]-[詳細設定]をクリックします。
  2.  [Outlook オプション] ダイアログの画面右側の [文字設定オプション] の以下の項目を設定変更します。
    “送信メッセージで優先使用するエンコード方法” で Unicode (UTF-8) を選択します。
  3.  [OK] をクリックしてダイアログを閉じます。

 

※対処方法 (2) の Outlook クライアントの既定の文字コードを Unicode (UTF-8) にすることで回避する理由は、Unicode (UTF-8) には日本語で一般的に使用する文字列がほぼカバーされているため、Exchange Server 側で Outlook と異なる文字コードと判定されず、問題がある処理が行われないためです。

 

 

その他
以下の公開情報にある問題は、本 Blog の現象の発生条件とエラーメッセージは同じですが、根本原因は異なります。

Title : "The operation failed" error in the Outlook client when you open a saved message from the Drafts folder and then try to send it
URL : http://support.microsoft.com/kb/2763886/en-us

本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

Friday with International Community Update – Progress in each language (Mar. 2018)

$
0
0

Hello, Wiki Ninjas!
Today is Friday with International Community Update.

The end of March is as follows:

The topic of this month:

  • This month, it seems that the whole movement was slow. Let's expect the next month!

Thank you!!

Tomoaki Yoshizawa (yottun8)
Blog: blog.yottun8.com
Facebook: Tomoaki Yoshizawa
twitter: @yottun8
TechNet Profile: Tomoaki Yoshizawa

New Office 365 URL categories to help you optimize the traffic which really matters

$
0
0

3rd April 2018

As part of the improvements Microsoft have recently announced to the way the required URLs and IPs for Office 365 are published, we have also changed how the URLs are categorized to help customers deliver best practice in terms of connecting to the required endpoints for the service.

In the current system, URLs are marked "Required" and "Optional" with a very large list of URLs in each category.

Traditionally Microsoft have always advised that customers optimize connectivity to Office 365 for the "required" endpoints. That often means, not using traditional proxy methods at the network edge due to the bottlenecks which commonly occur at this point. This is often due to the load Office 365 puts on these devices. In addition, the work often done at this layer such as SSL inspection for AV scanning or DLP which is often replicated in the application/service itself when it comes to Office 365 endpoints. Proxying traffic also often means Skype must use TCP for voice/media calls as opposed to its preferred method of using UDP directly, with an all too common drop in performance. More on the challenges with using traditional proxies for SaaS services like Office 365 can be found in another of my blog posts.

The difficulty with this categorization of the URLs (Required & Optional) is that applying this advice has become increasingly difficult for customers as the Office 365 service has grown. The number of endpoints in the "Required" list is now considerable, and the fact some do not live on Microsoft infrastructure (eg CDNs) for which we do not provide IPs for, and a customer may understandably want to apply SSL inspection on some of these endpoints due to the number and differing nature of them. It's also hard to correlate which URLs have which security features (such as AV scanning/DLP) applicable to it within the service, and thus don't require it at the network edge. The net result is that often key Office 365 traffic ends up being sent via an unoptimized path and encounters performance issues as a result, or it is a large challenge to optimize the full list of endpoints.

We therefore set about a piece of work to analyze all the URLs for the service and identify those which really require optimization to enable customers to focus on the traffic which really requires special consideration, i.e. those which are either very high volume in terms of bandwidth/transactions/connection count and thus put heavy load on proxies, or those which are particularly latency sensitive and require the direct path with minimal interference, for example Skype voice traffic.

This piece of work showed that a very small number actually require the highest levels of optimization, in the order of around 10 endpoints. This small list however accounts for 75-90% of Office 365 Bandwidth, connection and transaction count. These core endpoints are those which will put massive load on traditional proxy infrastructure and/or require that optimized path a direct egress best provides.

With this small list in mind, we can now work around the problem with traditional egress models in a much more precise manner, by concentrating on optimizing the URLs which both cause the problem (in terms of load) and also are the biggest victims of it in terms of performance.

We have therefore categorized the URLs into the following three categories to help customers deal with the endpoints in specific ways according to the needs of the endpoint and the business.

 

  • Optimize for a small number of endpoints that require low latency unimpeded connectivity which should bypass proxy servers, network SSL break and inspect devices, and network hairpins.
  • Allow for a larger number of endpoints that benefit from low latency unimpeded connectivity. Although not expected to cause failures, we also recommend bypassing proxy servers, network SSL break and inspect devices, and network hairpins. Good connectivity to these endpoints is required for Office 365 to operate normally.
  • Default for other Office 365 endpoints which can be directed to the default internet egress location for the company WAN.

 

Use of these categories, how they simplify connectivity to Office 365, and what actions you can take to make use of them is detailed in Office 365 Network Connectivity Principles.

 

Optimize Category

 

URLs in the Optimize category all have the following characteristics:

 

  • Are Microsoft owned and managed endpoints located on Microsoft infrastructure.
  • Have IPs provided
  • Are routable via ExpressRoute (If the circuit is authorized for this type of route).
  • Are High volume and/or latency sensitive
  • URLs in this list shouldn't change on a regular basis (IPs are likely to)

 

The Optimize list at the time of publishing is outlined below.

 

Endpoint to Optimize

Port/s

Use

https://outlook.office365.com

TCP 443

This is one of the Core URLs Outlook uses to connect to its Exchange Online server and has high volume of bandwidth usage and connection count. Low network latency is required for online features including: Instant search, Other mailbox calendars, Free / busy lookup, manage rules & alerts, Exchange online archive, Emails departing the outbox.

https://outlook.office.com

TCP 443

This is use for Outlook Online web access to connect to its Exchange Online server and network latency. Connectivity is particularly required for large file upload and download with SharePoint Online.

https://<tenant>.sharepoint.com

TCP 443

This is the primary URL for SharePoint Online and has high volume of bandwidth usage.

https://<tenant>-my.sharepoint.com

TCP 443

This is the primary URL for OneDrive for Business and has high volume of bandwidth and possibly high connection count from the OneDrive for Business Sync tool.

https://*word-edit.officeapps.live.com

TCP 443

Word Online, Excel Online, PowerPoint Online, and OneNote Online are frequently used with SharePoint Online from the web browser interface. Good network performance with low latency is required for these to support SharePoint Online.

https://*excel.officeapps.live.com

TCP 443

https://*powerpoint.officeapps.live.com

TCP 443

https://*onenote.officeapps.live.com

TCP 443

Skype for Business Media IPs (no URL)

UDP 3478, 3479, 3480, and 3481

Relay Discovery allocation and real time traffic (3478), Audio (3479), Video (3480), and Video Screen Sharing (3481). These are the endpoints used for Skype for Business and Microsoft Teams Media traffic (Calls, meetings etc). Most endpoints are provided when the Skype for Business client or the Microsoft Teams client establishes a call (and are contained within the required IPs listed for the service). Skype for Business today requires DNS lookup for *.lync.com for this to work. UDP is required for optimal media quality.

  

 

The above (optimize) endpoints will require access to the following IP address ranges:

 

Moving forward, this information will be available from the new provisioning system (currently in preview) and the following scripts will obtain this information for you using the latest data.

  • *Im still ironing out a few kinks in these scripts so please check back shortly.

Remember that the service these scripts pull from is currently in preview and whilst we aim to ensure accuracy of the data, there is no 100% guarantee until the service is in production, so it's worth double checking the IP ranges against the URL & IP page.

For all customers, the advice is that, for the endpoints noted above, where possible:

  • If proxies are in use, send the above URLs direct in the PAC file and allow a direct path through a firewall/NAT which has an allow list for the IPs and Ports listed.
  • Ensure devices and paths handling this traffic can scale to handle the demand in terms of port requirements and bandwidth.
  • Bypass or whitelist these URLs on network devices which do SSL decryption, DPI or content filtering, or any other interference of the traffic which could delay it. Look at applying the security elements your require, for these endpoints, within the service and thus allow the traffic out of the network without hindrance.
  • Egress these endpoints as close as possible to the users so the traffic can hit Microsoft's infrastructure locally.
  • For remote users ensure these endpoints are sent direct via split tunnelling if VPN solutions are used
  • Ensure that DNS resolution for these endpoints is done at the same location as the egress path

The advantage of the above list is we can send a customer's specific, and high-volume OneDrive/SharePoint traffic (tenantname.sharepoint.com & tenantname-my.sharepoint.com) direct, and apply DLP in the service if required, whilst sending any other tenant traffic (*.sharepoint.com) which may be required for sharing/collaboration, via an inspecting proxy.

Whilst most customers do not require it, if strict control of which tenants are accessible then tenant restrictions can be implemented to control which tenants can be accessed from within the corporate network.

By optimizing this list of endpoints, you can ensure that the traffic which is likely to put the most load on your network infrastructure, and/or is latency sensitive is treated in such a way that the service performs at its best, whilst removing the risk of overloading your standard network egress.

 

Allow Category

Access to the URLs marked as 'Allow' are required for Office 365 to function, however they are not as sensitive to network performance and latency as those marked as 'Optimize'. The amount of bandwidth these endpoints will consume is a small proportion of the whole figure and also connection counts will be lower than the optimize category.

Allow endpoints have the following characteristics:

  • Are required for the service to function
  • Are not as highly sensitive to network performance as the optimize category
  • Are not comparatively high bandwidth or connection count endpoints
  • Higher rate of change than the optimize category
  • Not all endpoints in this category will have IPs provided

Whilst these endpoints are required for the services to work and aren't as sensitive as the Optimize URLs, they still are critical to the running of the service. A heavy delay to connectivity to one of these endpoints could cause performance issues for users. As such it is recommended that these URLS are optimized as far as possible.

Recommended advice in an ideal situation is as follows:

  • If possible, bypass or whitelist Allow endpoints on network devices and services that perform traffic interception, SSL decryption, deep packet inspection and content filtering. If it is not possible to bypass these URLs, ensure the work is as light touch as possible, and on optimized, well scaled devices which minimize any delay.
  • If proxying this traffic, ensure proxy authentication for these URLs is disabled to remove any delay that may cause.
  • If possible, prioritize the evaluation of these endpoints as fully trusted by your network infrastructure and perimeter systems.
  • Egress these endpoints as close as possible to the users so the traffic can hit Microsoft's infrastructure locally.
  • Ensure that DNS resolution for these endpoints is done at the same location as the egress path
  • Prioritize these endpoints for SD-WAN integration for direct, minimal latency routing into the nearest Internet peering point of the Microsoft global network.

     

    I'm also working on scripts to display this category in the right way, check back here for updates.

     

    Default Category

     

    This final category represents endpoints for Office 365 services and dependencies that do not require any optimization and can be treated by customer networks as normal Internet bound traffic.

     

    • Some endpoints in this category may not be hosted in Microsoft datacenters.
    • Some endpoints in this category may not have IPs provided for them (so require a proxy or other unrestricted path)

       

    Im also working on scripts to display this category, check back here for updates.

     

    Hopefully this new categorization helps your organisation to simplify the connectivity requirements for the Office 365 service by optimizing the core endpoints which really require it. Please leave your feedback for this feature at the Tech Community site where we have our official information available.

    Paul

Current Cumulative Updates for Office – Q2 2018

$
0
0

As I mentioned in the Current Cumulative Updates for Office - Q3 2012 post, each quarter I will post information on the latest updates for the Office for Windows and Office for Macintosh products.

The information below is being provided regarding the most currently available updates available for the supported Windows and Macintosh versions of Office as of April 1, 2018.

Release Schedule for Non-Security Updates

  • For the MSI version of Office, non-security updates are released in Microsoft Update and the Windows Server Update Service (WSUS) on the first Tuesday of the month.  This will include all updates that have the Critical or Definition classification.  Updates with the Security classification will continue to release on the second Tuesday as usual.
  • For the Click-To-Run (C2R) version of Office, all updates will release on the second Tuesday of the month.

As a reminder on why I'm providing this information and how it should be used, please see my Keeping Up with Office Updates post which discusses the cumulative updates for Office (and Outlook in particular) that companies need to be aware of and push out to their users.

Office for Windows

Office 2016

Office 2013

Office 2010

Office 2007

Office 2003

  • Office 2003 reached End-of-Life Support on April 8, 2014

Click-to-Run:

June 2017 Versions:

  • Office 2013: 15.0.5015.1000
  • Office 2010: 14.0.7196.5000

Note: Each of the KB articles includes the list/links for all the Office products (Word, Excel, Outlook, etc).  Most of you focus on Outlook and that's the only ones required and is also provided separately but I wanted to provide the larger "Office" list in case you want it.

As a reminder, Microsoft Update does *NOT* make the cumulative updates available to users (unlike the Public Updates) for products prior to Office 2013.  These have to be downloaded and either installed independently or deployed using tools such as WSUS, SCCM, etc.

Note: As of January 1, 2015 the Office product group has made a decision to no longer have both what were known as "Public Updates" (those that you could get through Microsoft Update) and "Cumulative Updates" (separate downloads) for the Office 2013 products, which has always been very confusing (and part of why I started posting this information).  Going forward, all updates will be part of the Public Update releases.  However, I will continue to post this bulletin quarterly so that you have this information to properly manage updates for desktops, etc.

Office for Macintosh

Office 2016

Office 2011

  • Current Service Pack Level: Microsoft Office for Mac 2011 SP7 (released Nov 15, 2016)
    • Office for Mac 2011 mainstream support ended on October 10, 2017
  • Latest cumulative Update: September 12, 2017 - 14.7.7 (http://support.microsoft.com/kb/3212225)

Note: Each of the KB articles includes the link for downloading the package which updates ALL Office Products...there are not separate updates for each of the various components of Office as there is with the Windows releases.


How do I qualify for the Signature Cloud Support benefit?

$
0
0

Review the Core benefits and requirements for information on the individual requirements for the Cloud Performance and Hybrid competencies.

Program overview

Microsoft Partner Signature Cloud Support is an exclusive technical benefit that provides qualified cloud competency partners with an elevated level of technical support for select Microsoft cloud products. You will receive access to technical support engineers who will work directly with you, have extensive product-specific knowledge, and are accountable for driving cases from start to finish.

Program benefits

  • Experienced Work with experienced engineers that are trained to an escalation level with extensive product specific knowledge.
  • Partner-centric Engineers work extensively with you and understand your business and priorities.
  • Solutions-oriented Engineers are accountable for end-to-end scenarios including hybrid deployments.

Technical benefits structure

Only gold and silver partners who obtain a cloud performance or hybrid competency are eligible for Signature Cloud Support. Please check your competencies to determine if you are eligible for Signature Cloud Support.

Signature Cloud Support Benefit Overview

Steps on how to create Signature Cloud Support Incident

Announcing General Availability for the Microsoft Intune App SDK Xamarin Bindings

$
0
0

By Aasawari Navathe | Intune PM

The Microsoft Intune App SDK Xamarin Bindings (previously known as the Microsoft Intune App SDK Xamarin Component) enables data protection features and mobile app management through Microsoft Intune for Xamarin-based apps on iOS and Android. We're moving from preview functionality to general availability! You can now deploy apps integrated with this release widely within your organization and to the public app stores. Many customers have shared they’ve been building cross-platform apps using Xamarin for their line-of-business needs, and some are also building public store apps. As such, we put a team of talented engineers to work thinking about how we can support our customers using Xamarin.

The bindings were designed specifically for use when building cross-platform mobile apps on the Xamarin platform, making it easy for developers to add in application protection policy (APP) controls as part of their standard app development process. If you are a developer building a cross-platform app, you can quickly add them to your project, with very little modification to your mobile app. Both are essentially embedding our native Intune App SDK functionality (so you get the same features) but you still maintain the value generated from the shared codebase of the Xamarin platform.

A handful of internal and external partners have already begun using this release successfully.

What exactly are we releasing?

  1. Microsoft.Intune.MAM.Remapper.Tasks: A MSBuild task to remap base class types and method names in dependencies for Android apps using Xamarin Forms.
  2. Microsoft.Intune.MAM.Xamarin.Android: A package for Xamarin.Android platform.
  3. Microsoft.Intune.MAM.Xamarin.iOS: A package for Xamarin.iOS platform.

The current release of Microsoft Intune App SDK Xamarin Bindings supports:

  • Visual Studio 2015 and Visual Studio 2017 up to release v. 15.6
  • Built with Visual Studio Tools for Xamarin v. 4.7.10.38
  • The Microsoft Intune MAM Remapper (used for Xamarin.Android apps) is compatible with Xamarin Forms v. 2.5.0.280555
  • ADAL libraries for Obj-C v. 2.5.4
  • ADAL for .NET v. 3.17.3
  • Built with the Intune App SDK for Android v. 4.4.2, thus supporting Android apps built up to API 27
  • Built with the Intune App SDK for iOS v 7.1.22, thus supporting iOS apps built targeted for iOS 9.3.5 and above

We plan on releasing some sample apps through our GitHub repository shortly to help developers understand how to use what we've made.

To get started, you can download the bits on GitHub at https://aka.ms/intunegithub. We also released this through NuGet here: https://www.nuget.org/profiles/msintuneappsdk. If you are not already using Intune, or want to test through a completely separate account, you can always get a Microsoft Intune trial to test your mobile app.

Additional resources:

Innovations and opportunities with Microsoft Teams

$
0
0

Last month at Enterprise Connect, we celebrated the one-year anniversary of Microsoft Teams and shared that over 200K organizations are using Microsoft Teams adding 75,000 new organizations in 6 months. Late last year, we announced that we were bringing the Skype for Business capabilities into Teams—since that announcement, we’ve seen nearly 70% of our Skype for Business enterprise customers in Office 365 begin using Teams.

We also announced new capabilities for Teams, including bringing new Skype for Business voice capabilities into Teams. Additional new capabilities deliver on our vision for Intelligent Communications, such as inline message translation and the ability to blur your background in meetings. On top of that, we announced cloud recording and that we’re bringing Teams to a full ecosystem of devices, which will include devices from Microsoft as well as our hardware partners, and announced new meeting room and phone devices that will support Microsoft Teams.

We also announced new enterprise-grade calling features in Teams, including consultative transfer, call delegation and federation. Today, Teams delivers chat-based collaboration, meetings, and calling. Now with Direct Routing, Teams will soon have full enterprise voice features. Direct Routing is a feature of Office 365 and Phone System that helps customers connect their SIP trunks directly from their network to Microsoft Teams. It will enable customers to use their existing telephony infrastructure with Teams for calling, targeting the end of Q2 2018 for general availability.

If you missed it, you can hear Bob Davis, Corporate Vice President of Office 365, unveil new announcements advancing our vision for Intelligent Communications at the Enterprise Connect 2018 conference keynote.

 

 

Partners: Be ready for Microsoft Teams

With the current momentum and roadmap feature gaps closing rapidly, now is the time for Partners to get ready for Teams! For those who have been part of this communication journey with Microsoft for a while, you already know that there is a rich partner opportunity. You can help your Office 365 customers start using Teams today, either independently or side-by-side with Skype for Business, depending on their requirements. You can support their migration of Skype for Business users when Teams capabilities are ready for them.

Partners can help their customers pilot Teams with voice. This scenario is useful when a company is not ready to fully migrate to Teams as a PBX solution, and wants to start from a small pilot. By integrating with existing PBX, pilot users can be moved to Teams with Phone System while remaining users stays on the third-party PBX. You can help your customers with network assessments, licensing evaluation, planning, migration from their existing PBX to Office 365 Phone System, and adoption services—just to name a few. There are packaging and resell opportunities with SIP trunking, SBCs for Direct Routing, as well as audio and video equipment and services. You can offer ongoing services to monitor their call quality and manage their hybrid environments.

There are other opportunities to extend Teams which has an open developer platform with a rich set of capabilities to build apps or integrate with new or existing business processes and services. You can create connectors, build apps, messaging extensions or even build domain specific bots that integrate with Microsoft Teams. To learn more about the Teams developer platform, visit the Office Dev Center.

Check out the Teamwork partner guidance page, which describes the value of the partner opportunity and includes an approach for building a roadmap for your customers on their digital transformation journey. For more resources, see Microsoft 365 Teamwork Extended Partner Opportunities, where you’ll find managed services opportunity suggestions and recommendations for providing professional services with packaged offerings. Some of these things may be new, but I'm betting that many are similar to services that you already know how to deliver. You’ll also find the Teams Quick Start kit and the Teamwork Assessment Kit resources to help you get started on a first engagement.

Join our community call

Please register for our US OCP community call, Partners: Be Ready for Microsoft Teams on Friday, April 13 at 10 a.m. PDT. I will be joined by Microsoft intelligent communications experts, who will recap the latest announcements from Enterprise Connect, as well as provide practical guidance for partners as you work with your customers in scenarios such as greenfield, compete, and advanced scenarios with voice. We’ll also go through an extensive exploration of Teams and associated opportunities, and answer any questions that you have on the call. We can’t wait for you to join us!

Modern Workplace Technical Community

 

 

【ウェブ セミナー】クラウドファースト時代のハイブリッドクラウド【4/7 更新】

$
0
0

 

本ウェブセミナーのレベルは L100です。
L100…マイクロソフトの製品群やテクノロジ群の方向性を説明し、ビジネス判断のためにテーマを理解できることを目指したレベル

IT予算の80%がメンテナンスに使われ、高額投資で実現する唯一のサービスが「仮想マシンの提供」、管理者は変化の無い管理タスクをただこなすのみの毎日。このような状況を抜け出すには、パブリッククラウドの有効活用と自社データセンター改革、そしてITを利用する側の視点にたった戦略が必要です。本セッションでは、陳腐化する自社データセンターとパブリッククラウド両方への向き合い方について説明します。

<アジェンダ>

•  15年間変わっていない企業ITの課題
•  4つのシームレスハイブリッドクラウド
•  データセンター改革のための3つの視点

高添 修 (http://blogs.technet.microsoft.com/osamut/)
パートナーテクノロジーストラテジスト
日本マイクロソフト株式会社

 

▼ 【ウェブ セミナー】クラウドファースト時代のハイブリッドクラウド の視聴はこちらから

 

 

 

How-to – Load Remote Exchange PowerShell Session on Exchange 2010, 2013, 2016, Exchange Online (O365)

$
0
0

1-Intro

In a previous blog post, I exposed the trick to load the Exchange Management Shell on ISE, the Integrated Scripting Environment of PowerShell, just like the Exchange Management Shell shortcut that is installed when you install the Exchange Management Tools. That trick needed the Exchange Management Tools to be installed locally, which is not bad as your ISE will behave exactly like your Exchange Management Shell, but with the benefits of the ISE.

Now, and as George highlighted in a comment in this previous blog post's comments section, you can also load Exchange cmdlets from a remote PowerShell session, using New-PSSession and Import-PSSession. Note that not all Exchange cmdlets and functions are available using that way (what you "lose" is a topic for a future blog post but basically you can just compare Exchange cmdlets list side by side after dumping these using "get-excommand")

As mentioned in the same previous blog post, that PowerShell session import method has its own advantages, like the ability to load Exchange management cmdlets to any workstation or server that has PowerShell and the proper ports opened, without the need to install the Exchange Management Shell. It can be very useful for your applications relying on Exchange Powershell cmdlets for example…

Below I pasted the PowerShell snippets to connect to your Exchange platform (Exchange 2010, 2013, 2016 and Exchange Online), along with the related TechNet links if you need or want more details.

 

2- Ports needed between management console and the remote server

Ports between that station and the remote Exchange server(s) or the remote Exchange Load Balancer must be opened – by default, your Exchange servers WinRM listener will use ports 5985 for HTTP and 5986 for HTTPS

  • To check which ports your Exchange servers listen to, you can run the following:

Get-WSManInstance –ResourceURI winrm/config/listener –Enumerate

Which will show the 5985 port only… meaning that if only port 80 is opened between your station and your Exchange server, you won't be able to import a PS Session from it – you will need to enable listening on "traditional" http and/or https ports, respectively TCP port 80 for HTTP and TCP port 443 for HTTPS, you will need to run the below on each of your Exchange servers you will want to connect to:

Set-Item WSMan:localhostServiceEnableCompatibilityHttpListener -Value true

Set-Item WSMan:localhostServiceEnableCompatibilityHttpsListener -Value true

  • Before adding the HTTP port 80 and/or HTTPs port 443 Listeners, Get-WSManInstance command above gives you :

cfg : http://schemas.microsoft.com/wbem/wsman/1/config/listener
xsi : http://www.w3.org/2001/XMLSchema-instance
lang : en-US
Address : *
Transport : HTTP
Port : 5985
Hostname :
Enabled : true
URLPrefix : wsman
CertificateThumbprint :
ListeningOn : {127.0.0.1, 192.168.2.51, ::1, fe80::5efe:192.168.2.51%13, fe80::d42:e6f1:faff:ecfb%12}

  • And after adding these using the two Set-Item WSMan commands, running the above Get-WSManInstance will output the previous one, plus the HTTP + HTTPS ones highlighted in yellow:

cfg : http://schemas.microsoft.com/wbem/wsman/1/config/listener
xsi : http://www.w3.org/2001/XMLSchema-instance
lang : en-US
Address : *
Transport : HTTP
Port : 5985
Hostname :
Enabled : true
URLPrefix : wsman
CertificateThumbprint :
ListeningOn : {127.0.0.1, 192.168.2.51, ::1, fe80::5efe:192.168.2.51%13, fe80::d42:e6f1:faff:ecfb%12}

cfg : http://schemas.microsoft.com/wbem/wsman/1/config/listener
xsi : http://www.w3.org/2001/XMLSchema-instance
Source : Compatibility
lang : en-US
Address : *
Transport : HTTP
Port : 80
Hostname :
Enabled : true
URLPrefix : wsman
CertificateThumbprint :
ListeningOn : {127.0.0.1, 192.168.2.51, ::1, fe80::5efe:192.168.2.51%13, fe80::d42:e6f1:faff:ecfb%12}

cfg : http://schemas.microsoft.com/wbem/wsman/1/config/listener
xsi : http://www.w3.org/2001/XMLSchema-instance
Source : Compatibility
lang : en-US
Address : *
Transport : HTTPS
Port : 443
Hostname : E2013N1.E2013CANADA.CA
Enabled : true
URLPrefix : wsman
CertificateThumbprint :
ListeningOn : {127.0.0.1, 192.168.2.51, ::1, fe80::5efe:192.168.2.51%13, fe80::d42:e6f1:faff:ecfb%12}

For more information about the above, you can check the below TechNet page:

https://blogs.msdn.microsoft.com/wmi/2009/07/22/new-default-ports-for-ws-management-and-powershell-remoting/

 

3- Code snippet to open a remote session to your Exchange environment

You can use the below snippets to test Exchange PowerShell "session remoting". I pasted here the code to connect to Exchange 2010, 2013, 2016 and Exchange Online, taken from the TechNet (now Microsoft Docs) pages for each technology – feel free to check the corresponding Microsoft Docs page if you want more information about these.

#For all versions, including for EoL, it's recommended you remove the PSSession as closing the PowerShell window will let the remote session opened on the server side, and the session will have to time out, and the quota for the maximum number of concurrent connections may prevent you from connecting back to the service on a timely basis.
#using Remove-PSSession $Session once finished will remove and close the remote session

For all Exchange on-premise versions, the below snippets come from this docs.microsoft.com link (these are progressively replacing the TechNet pages).

For Exchange Online, the snippet come from this docs.microsoft.com link.

Exchange 2010 with current user

#Exchange 2010 with current user
$ExchangeOrNLBFQDN "E2013N1.E2013Canada.ca"
$Session New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "http://$ExchangeOrNLBFQDN/PowerShell/" -Authentication Kerberos
Import-PSSession $Session

#(Remove-PSSession $Session once finished)

Exchange 2010 with other user (Run As)

#Exchange 2010 with other user (runAs type)
$ExchangeOrNLBFQDN "E2013N1.E2013Canada.ca"
$UserCredential Get-Credential
$Session New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "http://$ExchangeOrNLBFQDN/PowerShell/" -Authentication Kerberos -Credential $UserCredential
Import-PSSession $Session

#(Remove-PSSession $Session once finished)

Exchange 2013

#E2013
#Exchange 2013 with other user (just like using RunAs) – to connect using the current user credentials, remove or comment the $UserCredential = Get-Credential line and remove the "-Credential $UserCredential" parameter from the $Session = New-PSSession...
$ExchangeOrNLBFQDN "E2013N1.E2013Canada.ca"
$UserCredential Get-Credential $Session New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "http://$ExchangeOrNLBFQDN/PowerShell/" -Authentication Kerberos -Credential $UserCredential
Import-PSSession $Session

#(Remove-PSSession $Session once finished)

Exchange 2016

#E2016
#Exchange 2016 with other user (just like using RunAs) – to connect using the current user credentials, remove or comment the $UserCredential = Get-Credential line and remove the "-Credential $UserCredential" parameter from the $Session = New-PSSession...
$ExchangeOrNLBFQDN "E2013N1.E2013Canada.ca"
$UserCredential Get-Credential
$Session New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "http://$ExchangeOrNLBFQDN/PowerShell/" -Authentication Kerberos -Credential $UserCredential
Import-PSSession $Session

#(Remove-PSSession $Session once finished)

Exchange Online (Office 365)

#EO365
#Exchange Online
$UserCredential Get-Credential
$Session New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Authentication Basic -Credential $UserCredential -AllowRedirection
Import-PSSession $Session

#(Remove-PSSession $Session once finished)

Viewing all 36188 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>