Please stay tuned for the coming release of Microsoft Dynamics AX R3 Cumulative Update 12 this Q4 of 2016.

System Center 2016 has been released. You can download trial version of products from Microsoft Download Center. You should register to use trial version. You can use the trial versions for 180 days. You can download Full versions from the MSDN web site with a valid subscription also. My advise is you should not install trial versions of System Center products on production environment as a main installation. Because you may not use the full version to convert the trial version to the full version. So you can lose all of your data. As you can see Windows Server 2016 has been released also. Let’s begin to enjoy the new products.

Windows Server 2016
System Center 2016

If you have read the Best Practices for Software Updates in Configuration Manager, you may have noticed that we recommend sharing the SUSDB for Software Update Points (SUPs) off the same Configuration Manager site server. A shared SUSDB setup is becoming increasingly common place, however it can be a bit confusing navigating exactly how to do it properly. This can lead to problems arising from configuration mistakes not-so-happy-little-accidents. To make sure you don’t have any of these problems, here’s some guidance on how to get this all setup properly.

Requirements

The requirements for a shared SUSDB are the same as for a NLB WSUS 6.X setup. All of the front end WSUS computers that are to share SUSDBs should be running the following:

1. The same version of WUSS.
2. The same version of Windows
3. The same Windows updates installed on the server.
4. The same WSUS patches should be installed on all computers that share the same SUSDB.

Also, SQL Server must meet the minimum database requirements. You may use a SQL cluster if you wish, but keep in mind that Windows Internal Database (WiDS) is not supported for sharing the SUSDB.

Lastly, you will need a shared WSUS content directory that you have already created using either a standard network share or Distributed File System (DFS). All of the WSUS computer accounts must have change permissions for the share.

PART I: Installing WSUS

You may install WSUS using this article via PowerShell if you wish, or by using Option 1, Step 1 of the NLB WSUS 6.X article. However, I will be using Server Manager followed by the post installation tasks run via PowerShell.  It is also worthwhile to note that when you install WSUS specific patches that you have downloaded files for, you would want to follow the guidance laid out for NLBs where you patch one node at a time.

1. Open Server Manager, click on “Manage” then select “Add roles and features”:

2. Follow the prompts until you get to “Server Roles”, then check “Windows Server Update Services” and click Next.

3. The Add Roles and Features Wizard will then pop up and offer to install any prerequisites needed. Click on “Add Features”, then click “next” to continue to Features. Skip through WSUS heading and get to “Role Services” for WSUS.

4. Uncheck “WID Database”, select “Database”, then click “Next”.

5. Fill in the share that you created as part of the previously mentioned requirements when you get to “Content”. In this case, the share is on the server I am currently installing WSUS on however it does not have to be on one of the WSUS computers. Take note of the author’s taste in music based on the domain name. There will be a pop quiz on it later. Click “Next”.

6. Fill in the SQL server name (Instance if needed) and click “Check connection”. The wizard will tell you if you successfully connected or not. If it successfully connected, click “Next”. If not, troubleshoot why your computer will not connect to the SQL server.

7. Click “Next” to get through the information about IIS, until you get to Web Server Role (IIS) Role Services. At this point, I usually like to add the HTTP logging for IIS since it is not added by default. Other Role Services can be added at this point if needed as well. Note that the default location for IIS logging is c:inetpublogslogfiles and you may want to change this default as well after you complete your install. After deciding if you want IIS logging or not, accept the rest of the default Role Services for IIS.

8. When you get to the Confirmation page, click “Install”, then click “Close” when finished.

9. Now we have to do some post installation tasks. You can do this a few different ways:

Option 1: Open the WSUS console and work through the prompts:

Option 2: Through Server Manager from the notification:

Option 3: Via PowerShell, which is my preference:

a) Launch PowerShell using administrator credentials.

b) Change to the C:Program FilesUpdate ServicesTools folder.

c) Run the following, filling in the information specific to your environment:

.Wsusutil.exe postinstall SQL_INSTANCE_NAME=”ServerInstance” CONTENT_DIR=”\Servernamesharename”

Notes on the post install configuration process

Please note that you need the “. “ in front of wsusutil.exe or it will not execute in PowerShell. For the default SQL instance, just type in the server name. You do need the quotes in the above command. It will launch the post install which installs the SUSDB, recreates the website on port 8530 (default) and points to the ContentDir. The post install command will create a log in the <user>AppDataLocalTemp directory which will be in the form of tmpXXX.tmp. This log may be 0kb for a little while. It will spawn another log called WsusUtilUseCustomWebSite.log. The website log will disappear if all goes well with the website install, then the tmpXXX.log will be written to at that point. The tmp log will show you the tables, stored procedures, views, etc being created/verified in the SUSDB.

10. Do these same steps for any other WSUS computers that will be Software Update Points (SUPs) off the same Configuration Manager Primary Site. You can have up to 4 front end WSUS servers sharing a SUSDB. If you are setting up WSUS to use SSL, additional WSUS configuration is required.

PART II: Verifying the WSUS Settings

1. Open IIS and expand it. Right-click the Content vDir and select “Manage Virtual Directory”, then “Advanced Settings”:

2. Under Physical Path, you may (or may not) notice that the path looks a little off. If you do not see \ in front of your server name, add it then click “Ok”.

This is wrong:

This is right:

3. Open the registry and navigate to HKLMSoftwareMicrosoftUpdate ServicesServerSetup. Check the registry keys below.

– ContentDir: This should be the same as the Content Directory you specified during the post install process.

– IISTargetWebsiteIndex: This is the IIS site ID. Your IIS logs are named after this by default:

– PortNumber: The default port is 8530. 8531 for SSL.

– SQLDatabaseName: This is always “SUSDB”. It is not supported to rename the database.

– SQLServerName: This is the ServerName (and Instance, if applicable).

– UsingSSL: Set to 0 for false and 1 for true.

4. This is optional, but you can also check the content location from the database. You can see that it automatically adds the WSUSContent directory at the end of it as IIS did for the vDir.

select LocalContentCacheLocation from tbConfigurationB

PART III: Installing the SUPs

1. Decide which SUP you want to install first. Typically I choose the server that is less utilized or that has better specifications as the first SUP to install if my servers are not quite exactly like each other.

2. Install your SUPs like you normally would. I am going to install my SUP role on my remote WSUS computer first, then install the SUP role directly on my primary site server second. Since this is a new computer to my environment, I select “Create Site System Server” from the Home tab under Administration –> Site Configuration –> Servers and Site System Roles, then type in the FQDN of the server and my installation account if needed.

Next set the proxy server and the credentials for it if needed.

Now select the Software Update Point Role and click “Next”:

Select your ports based on what you saw in Part II, Step 3 in the registry:

Configure any additional settings for the proxy, then step through the rest of the wizard to finish installing the role.

You will see the new machine show up under Servers and Site System Roles.

3. Monitor SUPSetup.log on the SUP computer along with WCM and WsyncMgr logs on the site server to see if you have any additional issues.

4. Add the next SUP off the site. Note that you may see that your SUP lists Microsoft Update as its source rather than the upstream WSUS. This is usually an indication that the WSUS configuration is pending, or it’s having issues like the one below. You will see the catalog version update when your computer finishes the first sync with the upstream server.

PART IV: Fixing Common Configuration Issues

Issue 1: The WSUS Content Directory is set to the wrong location

One of the most common configuration issues I run across is that the WSUS Content Directory is set to the wrong location for one of the WSUS front end servers. Typically content files for updates are not stored in the WSUS Content Directory when using Configuration Manager to install patches, however it is used for EULA files. A clue that this may be your issue is machines reporting they can’t find a EULA file in the WindowsUpdate.log/etl:

WARNING: Fail to download eula file http://JoyDivision:8530/Content/AE/C324C69722CB5F82E63CE9C6D73CFBF8675309AE.txt with error 0x80244019

To resolve this, first verify the steps from Part II above for the computer you are attempting to get the text file from. Usually you will see that something does not match. It’s important to know that the registry will not show the directory “WSUSContent” directory at the end of the path, unlike SQL and the IIS virtual directory for content. In this example, all of my settings seem to be pointing to D: on this WSUS front end server rather than the share name \2012R24GB.

We already know what the problem is, but there are a few other symptoms that point to this being the issue as well. For example, I can’t browse to the URL of txt file above and IE notes it is 404’d:

If I right-click on the Content virtual directory in IIS from the front end WSUS and select “Explore”, I see that the directory is empty (not always though):

I can see that the file is in the share:

TIP: WSUS files places the files in the directory that matches the last two places of the file name. In this case it would be AE.

Now that we know what the problem is, let’s fix it! Run WSUSutil postinstall from PowerShell to set the correct location (see part I, step 3 above):

Verify all of the items from IIS, the registry as well as SQL to ensure they are set correctly.

Next, run a WSUSutil reset to verify and re-download any missing files:

Verify that the reset is running from C:Program FilesUpdate ServicesLogfilesSoftwareDistribution.log on the front end WSUS computer. You will see a notification event for it typically followed by a reporting event that Content Sync started:

Issue 2: Some front end WSUS computers cannot access the shared content directory

Another fairly common problem is when some of the front end WSUS computers are unable to access the shared content directory for some reason. Normally you will see some sort of 401 error (401.3’s mostly) in the IIS logs when trying to get a content file. You will also see errors from the Windows Update Agent in windowsupdate.log.

A typical Windows Update error on a client will look something like this:

WARNING: WinHttp: SendRequestUsingProxy failed for http://JoyDivision:8530/Content/AE/C324C69722CB5F82E63CE9C6D73CFBF8675309AE.txt error 0x800710dd

Here is a typical IIS error logged at the same time:

10.10.10.5 HEAD /Content/ AE/C324C69722CB5F82E63CE9C6D73CFBF8675309AE.txt 8530 – 10.10.10.221 Windows-Update-Agent – 401 3 5 281

Frequently the resolution for this is to change the pass-through authentication settings on the Content VDir in IIS. Check out the diagram for how this works.

To do this, first highlight the Content vDir for WSUS in IIS then double click “Authentication”:

Next, click on Anonymous Authentication and select “Edit”:

Change this from IUSER to Application Pool Identity and click “OK”. Keep an eye on the IIS logs for any errors when accessing content to help determine if this resolves the problem.

Note the WSUSPool’s identity:

Tips for troubleshooting other permission problems

1. Verify permissions listed here.

2. Use a check file for testing and troubleshooting. To do this, create an empty text file in the WSUSContent folder and call it ContentFolderAclsCheck.txt, then restart the WSUS Service. Now run wsusutil checkhealth and check the application event log to assure no 10012 errors for the content directory. Verify that the contentfolderaclscheck.txt is no longer there. the CheckHealth parameter will process the file and remove it if permissions are working correctly.

Part V: Performance Tips

1. I like to just go ahead and modify the WSUS Application Pool’s memory limit for recycling since I know approximately what the memory usage is during peak scanning times in my lab.

Appcmd can be used to determine the PID of the process running WSUS AppPool. To do this, from an elevated Command Prompt, change to the WindowsSystem32inetsrv folder amd run appcmd.exe list wp to get a list of Application Pools and their PIDS. You can see here that my WSUS isn’t very busy right now since I just built it and have no clients scanning against it:

2. Right after I finish my first sync, I like to go ahead and schedule WSUS Maintenance and run it for a few different reasons:

a. Primarily, I run this directly after my first sync to go ahead and decline superseded updates that I know I will not be deploying so that my clients will scan faster and my WSUS computers do not consume resources for items I don’t need. The WSUS will sync these in initially since they are in the catalog.

b. Since I just got a fair amount of updates imported, I might as well reindex the SUSDB while I am looking at it.

c. I also like to test my scheduled tasks so I am confident they will kick off on schedule.

I hope this information helps, and if you are interested in taking this to the next step and using NLB for your SUP, take a look at my buddy Cameron’s article here.

As always, thanks to The Scripting Guy for the scripts and to my colleague Vinay Pamnani for his valuable input.

Meghan Stewart, Support Escalation Engineer
Microsoft Enterprise Cloud Group

Heyecan ile beklenen yeni ürünler yayınlandı.

Azure Traffic Managerとは

Azure Traffic ManagerはDNSレベルでトラフィックを制御するL4ロードバランサです。
ワールドワイドに散らばったリソースにも負荷分散できるという特徴があります。
DNSレベルでトラフィックを制御することができるため事業継続性や災害対策などのクリティカルなサービスで活用することが出来ます。

主な特徴

アプリケーションのダウンタイムを短縮

Traffic ManagerはAzureの内部と外部のサイトおよびサービスを監視することが出来ます。
障害発生時にユーザーを新しい場所に自動転送することで、可用性を挙げることが出来ます。

アプリのパフォーマンスとコンテンツ配信性能を向上

ユーザーを自動的にAzure内外のネットワーク待ち時間が最も短い場所へ誘導することで、アプリケーションの応答性を向上させます。
それによって、コンテンツの配信にかかる時間を短縮し、ユーザーエクスペリエンスを高めます。

トラフィックを複数の場所へ分散

複数のクラウド サービスや複数のAzure Web Appsなど、複数の場所にトラフィックを分散できます。
また分散の方法も、均一負荷分散・加重負荷分散のいずれかを選択できます。

オンプレミスデータセンターで使用

Traffic Managerは、クラウドへのバースト、クラウドへの移行、クラウドへのフェールオーバーなど、オンプレミスのシナリオにも適用可能です。
ダウンタイムを意識せずに、オンサイト データセンターのアップグレードまたは保守を行うことができます。

複数のトラフィック ルーティング オプションを選択可能

Azure Traffic Manager では以下のルーティングオプションをアプリケーションやシナリオに合わせて選択できます。

• フェールオーバー
• パフォーマンス
• 加重ラウンドロビン

複数のロードバランサーの違い

	Azure Traffic Manager	Azure Load Balancer	Application Gateway
OSI参照モデルのレイヤ	L4	L4	L7
制御レベル	DNSレベル	IPアドレス	URLやHTTPヘッダ
特徴	ワールドワイドに散らばったリソースにも負荷分散でき、 DNSレベルで制御するため事業継続性や災害対策などのクリティカルなサービスで必要になる	ILB(Internal Load Balancer) と ELB(External Load Balancer) のどちらとしても使える	SSLオフロード機能、Cookie処理による振りわけ等に対応可能

Good news, Hyper-V Server is now available on the TechNet Evaluation Center.

Description

Microsoft Hyper-V Server delivers enterprise-class virtualization for your datacenter and hybrid cloud. Hyper-V Server 2016 provides new and enhanced features that can help you deliver the scale and performance needs of your mission-critical workloads.

Preinstall Information

1. Review Windows Server 2016 release notes and system requirements (Hyper-V Server 2016 documentation included)
   
2. Receive email with resources to guide you through your preview

Installation Guidelines

Upon installation you will be prompted to activate. A product key is not required.

Resources For Your Evaluation

What’s New in Hyper-V Server 2016
Release Notes
Getting Started with Hyper-V Server 2016

For those of you who have been waiting for evaluation of the RTM version to become available you will be happy to hear that you can grab it now from the TechNet Evaluation Center.

Description

For those of you with the appropriate MSDN subscriptions head on over to the Subscriber Downloads page to grab the release builds of Windows Server, Windows Server Essentials, Hyper-V Server and Storage Server. My guess is that more than a few of you are going to be spending the weekend updating or building your Windows Server 2016 test environments…

In a new style of article the International Airline Group’s digital team team joined up with Microsoft to build a prototype bot for the IAG’s frequently asked questions. The Bot needed to be able to answer the questions in the most seamless way possible, so how did they do it?

Editors’ Note: this post may be a bit of a departure from the style of article you’re accustomed to on TechNet, but hopefully it gives our longtime IT Pro readers a glimpse into the kind of detailed technical discussions that our audience from the developer network know and love. Enjoy!

By Jamie Dalton

A look inside the recent collaboration with IAG

The Audience

In July the International Airline Group (IAG) digital team worked alongside Microsoft to build a prototype for a Frequently Asked Questions (FAQ) bot.  The goal was to build out a Proof of Concept (PoC) for IAG to see how they could open up new conversational channels to their existing customer base across their operating companies including Aer Lingus, Avios, British Airways, Iberia and Vueling.  IAG’s customers have strong brand loyalty and being able to answer their needs in the most friction-free way is key to their customer service.

Hackfest team was formed as: Jamie Dalton (Microsoft), Gary Newby (IAG), James Crosthwaite (IAG), Andy Qua (IAG), Toby Bradshaw (Microsoft), Jason Fox (Microsoft), Ana Hidalgo de la Vega (IAG), Ami Turgman (Microsoft) and Simon Michael (Microsoft) – from left to right in the picture – Dan Jobling (IAG) and Lee Harvey (IAG).

Technologies used

The technologies used to build out the PoC were:

• Web: NodeJS
• Package Management: NPM
• Azure App Services: Azure App Service
• Azure Application Insights and Analytics: App Insights
• Bot Platform: Dev Bot Framework
• QnA Maker: QnA Maker
• Development tools: VS Code, ngrok, Github
• Blog storage: Azure Blob Storage
• Document storage: DocumentDB

 Agile methodology

An agile approach was taken by creating a shared vision of success, to then be able to triage and prioritise tasks from the Product Backlog. Once agreement on which user stories to address had been made, these were broken down into tasks that could be allocated to the hackfest participants.

The Solution

The first step was for each developer to login to the MS Bot Framework portal and create their own individual bots, so that they could debug and run their code against them locally.  We used the ngrok tool which works by creating a secure tunnel to localhost, allowing developers to configure their localhost bots to the messaging endpoint in the bot portal.  We followed the below steps to get the debug environment up and running:

1. Create a bot on Dev Bot Framework
2. Run the bot website on localhost with a known port, e.g. 3978
3. Run ngrok against that port (ngrok http 3978)
4. Update the messaging endpoint of the bot in Step #1 to the generated ngrok endpoint
5. Chat to the bot using the channel that we were developing against e.g. Skype,Slack, etc.

The next task was to setup a Github repository and a corresponding Azure App Service website.  Once this had been done it was configured with continuous deployment against the repo, so we could gain early sight of progress as developers pushed each commit to the central repository.

IAG wanted to create separate bots for the different operating companies. These bots would need to analyse the question being asked by users and determine the most appropriate answer.  The QnA Maker was used to do much of the heavy processing, as it is capable of creating a knowledge base of questions and answers from existing content.  In this case, the service pointed to an existing FAQ url or data file and generated a service endpoint.

We needed one service endpoint for each operating company’s existing FAQ bot. Once the services were created we trained them to ensure they give the correct answers.

Within our sprint we added some stretch goals.  One of these was to add telemetry to the bot, this is a recommended practice as it is important to see how your users are interacting with it and ensure that it is adding value.  Application Insights was implemented to log whenever the user was given an un-helpful answer.  This not only allows IAG to update their FAQ, but to regenerate the QnA Maker backend service to provide better responses in future.

Challenges

IAG wanted to demonstrate how different types of media would be displayed on various conversational channels by initially focusing on Facebook Messenger, Skype and Slack.  The existing FAQ contained simple question and answer text. It needed corresponding multimedia metadata associated to it – which could then be served up in the response.  We wanted to showcase carousel and video responses.  Whilst we were able to display text, images and hyperlinks, Skype does not currently support video playback.  We therefore defaulted to displaying a hyperlink which opens the video within a browser.

IAG also wanted to be able to “channel hop”, the ability to start a conversation in one channel and then move it to another including the context.  We used the scenario of beginning a conversation in Skype and then transferring to the Avios mobile application.  To solve this, a combination of DirectLine channel and a backend store of conversation history was implemented.  Afterwards, a deep-link with a token was displayed within the conversation to redirect the user to the mobile application, where state could be retrieved based on the token.

Partner Feedback

Dan Jobling, Disruptive Tech at IAG, said: “Bots could play an important role in our customer experience and internal applications. It is important to prototype with the latest bot technology to explore the possibilities within our business.”

Opportunities for reuse

Any FAQ-based bot can leverage the QnA Maker, it is a great tool to quickly provision a powerful backend question/answer service that your own bot can implement.  This solution leverages this approach, whilst demonstrating multimedia support across channels and how to support “channel hopping”.

At the Ignite Conference, the Microsoft Azure product team announced support for Internet Protocol version 6 (IPv6) for Azure virtual machines (VMs). What this means is that Azure VMs can now send and receive native IPv6 traffic, provided they:

• Have network interfaces configured to request private IPv6 addresses.
• Are members of an external load balanced set that has been configured with a public IPv6 address.

Here is the basic configuration:

For additional information, see Overview of IPv6 for Azure Load Balancer.

To ensure that a VM has this new capability, you must first create an external load balancer that has:

• A front-end public IPv6 address
• A backend IPv6 address pool
• Rules that allow specified types of IPv6 traffic (such as unsolicited inbound traffic to TCP port 80)
• NAT rules to map ports from external to internal port numbers (as needed)

Here is an example Azure PowerShell code block that accomplishes this with the IPv6-specific code bolded:

$ipv4DomainName=”<unique DNS name for the IPv4 endpoint>”
$ipv6DomainName=”<unique DNS name for the IPv6 endpoint>”

# Create the Azure Public IP address resources for the front-end IP address pool
$publicIPv4 = New-AzureRmPublicIpAddress -Name “pub-ipv4“ -ResourceGroupName $rgName -Location $locName -AllocationMethod Static -IpAddressVersion IPv4 -DomainNameLabel $ipv4DomainName
$publicIPv6 = New-AzureRmPublicIpAddress -Name “pub-ipv6“ -ResourceGroupName $rgName -Location $locName -AllocationMethod Dynamic -IpAddressVersion IPv6 -DomainNameLabel $ipv6DomainName

# Create front-end address configurations that use the public IP addresses.
$FEIPConfigv4 = New-AzureRmLoadBalancerFrontendIpConfig -Name “LB-Frontendv4” -PublicIpAddress $publicIPv4
$FEIPConfigv6 = New-AzureRmLoadBalancerFrontendIpConfig -Name “LB-Frontendv6” -PublicIpAddress $publicIPv6

# Create back-end address pools.
$backendpoolipv4 = New-AzureRmLoadBalancerBackendAddressPoolConfig -Name “BackendPoolIPv4”
$backendpoolipv6 = New-AzureRmLoadBalancerBackendAddressPoolConfig -Name “BackendPoolIPv6”

# Create load balancer rules for Web and RDP traffic
$lbrule1v4 = New-AzureRmLoadBalancerRuleConfig -Name “HTTPv4” -FrontendIpConfiguration $FEIPConfigv4 -BackendAddressPool $backendpoolipv4 -Protocol Tcp -FrontendPort 80 -BackendPort 8080
$lbrule1v6 = New-AzureRmLoadBalancerRuleConfig -Name “HTTPv6” -FrontendIpConfiguration $FEIPConfigv6 -BackendAddressPool $backendpoolipv6 -Protocol Tcp -FrontendPort 80 -BackendPort 8080
$RDPrule = New-AzureRmLoadBalancerRuleConfig -Name “RDPrule” -FrontendIpConfiguration $FEIPConfigv4 -BackendAddressPool $backendpoolipv4 -Protocol Tcp -FrontendPort 3389 -BackendPort 3389

# Create the load balancer
$NRPLB = New-AzureRmLoadBalancer -ResourceGroupName $rgName -Name “myNrpIPv6LB” -Location $locName -FrontendIpConfiguration $FEIPConfigv4,$FEIPConfigv6 -BackendAddressPool $backendpoolipv4,$backendpoolipv6 -LoadBalancingRule $lbrule1v4,$lbrule1v6,$RDPrule

When you create the VMs, you must:

• Request a private IPv6 address configuration from the backend IPv6 address pool of the load balancer.
• For the VMs network interface, specify two IP configurations: one for the IPv4 endpoint and one for the IPv6 endpoint. You must still configure IPv4 connectivity to ensure that Azure VMs can get to Azure and Internet resources that are currently only available over IPv4.

Here are example Azure PowerShell commands that accomplish this with the IPv6-specific code bolded:

# Request IPv4 and IPv6 private address configurations
$vm1nicIPv4 = New-AzureRmNetworkInterfaceIpConfig -Name “IPv4IPConfig” -PrivateIpAddressVersion “IPv4” -Subnet $backendSubnet -LoadBalancerBackendAddressPool $backendpoolipv4
$vm1nicIPv6 = New-AzureRmNetworkInterfaceIpConfig -Name “IPv6IPConfig” -PrivateIpAddressVersion “IPv6” -LoadBalancerBackendAddressPool $backendpoolipv6

# Create the network interface
$vm1nic = New-AzureRmNetworkInterface -Name “vm1nic” -IpConfiguration $vm1nicIPv4,$vm1nicIPv6 -ResourceGroupName $rgName -Location $locName

NOTE: These code blocks are just examples and are not complete or intended to run successfully from the command line or in the Integrated Script Environment (ISE). They rely on previously-defined variables (such as $rgName, $locName, and $backendsubnet).

IPv6 for Azure VMs and Office 365

IPv6 connectivity to Azure VMs enables integration between Office 365 services and apps that also support IPv6 and apps or storage located on Azure VMs. The network path from the client computer or device to the app or storage on an Azure VM and Office 365 can be a native IPv6 path, without having to translate IPv6 traffic to IPv4 or tunnel it across an IPv4 network.

Here is the basic configuration:

For more information, see IPv6 support in Office 365 services.

This is just a short note that you should be careful installing Patch https://support.microsoft.com/en-us/kb/3192392 on Windows 2012R2/8.1 systems with the SCOM 2012 R2 console installed. It might happen that the console crashes regularly after the Patch installation. So please test this patch in your test environment carefully!

If you already installed the Patch and experience the issue, simply uninstall the patch on the affected systems.

I will keep you up to date if more information is available.

All credits and thank’s to my colleague Mihai Sarbulescu for finding this issue!

本記事は、.NET ブログの “.NET Framework Monthly Rollups Explained” (2016 年 10 月 11 日米国時間公開) を翻訳した記事です。

すべての適用可能な .NET Framework 用の更新プログラムをシングル ステップでインストールする新しくシンプルな方法として、.NET Framework 用の月例のロールアップを以前紹介しました。この新しいリリースについて、さらに詳細を説明します。

この記事では、インストール可能な 3 種類の月例の更新プログラムについて説明します。また、インストール プロセスの見え方、および新しいモデルに対するよくある質問と回答を提供します。

この新しい月例のリリースの導入は、Windows の月例のロールアップ モデルと足並みをそろえることを目的としています。

月例のリリース

3 種類の更新プログラムが提供されます。以下の説明を読み、お客様の環境に最適な更新プログラムを選択してください。

セキュリティおよび品質ロールアップ

セキュリティおよび品質ロールアップは、コンシューマーや開発者が使用するコンピューターへ適用することをお勧めします。セキュリティと品質の両方の修正が含まれ、累積的であるため、直前までのロールアップに含まれるすべての更新プログラムが組み込まれています。そのため、以前の更新プログラムを適用していなくても、最新のロールアップを適用することで容易にシステムを最新の状態に保つことが可能になります。セキュリティおよび品質ロールアップは、Windows Update および Windows Update カタログから提供されます。

• 提供時期: 毎月第 2 火曜日 (米国時間) 。Patch Tuesday とも呼ぶ
• 提供方法: Windows Update、Windows Server Update Services (WSUS) および Microsoft Update カタログ
• 累積的かどうか: はい
• 内容: セキュリティおよび / または品質に関する修正

セキュリティのみの更新プログラム

セキュリティのみの更新プログラムは、本番環境のコンピューターへ適用することをお勧めします。その月の新規のセキュリティ更新プログラムのみが含まれます。そのため、適用するセキュリティ更新プログラムを微調整することができます。既に当月のセキュリティおよび品質ロールアップをインストールしている場合、システムは最新の状態であり、セキュリティのみの更新プログラムをインストールする必要はありません。セキュリティのみの更新プログラムは、Windows Server Update Services (WSUS) および Microsoft Update カタログから提供されます。

• 提供時期: 毎月第 2 火曜日 (米国時間)。Patch Tuesday とも呼ぶ
• 提供方法: Windows Server Update Services (WSUS)、Microsoft Update カタログ
• 累積的かどうか: いいえ
• 内容: セキュリティに関する修正

品質ロールアップ プレビュー

品質ロールアップ プレビューは、品質に関する修正が利用可能になり次第ただちに適用またはプレビューしたい大企業にお勧めします。通常、プレビューで提供された品質に関する修正は 3 週間後に公開されるセキュリティおよび品質ロールアップに含まれます。品質ロールアップ プレビューは、Windows Update、Windows Server Update Services (WSUS) および Microsoft Update カタログから提供されます。

• 提供時期: 通常、毎月第 3 火曜日 (米国時間)。Patch Tuesday の 1 週間後
• 提供方法: Windows Update、Windows Server Update Services (WSUS) および Microsoft Update カタログ
• 累積的かどうか: はい
• 内容: 品質に関する修正

関連情報

以下はよくある質問に対する回答です。

以前公開された更新プログラムの扱いについて

セキュリティおよび品質ロールアップと品質ロールアップ プレビューには、以前公開されたすべての .NET Framework 4.5.x および 4.6.x 用の更新プログラムが含まれます。

新しいモデルへの移行直後は、以前公開されたすべての .NET Framework 3.5 用の更新プログラムがロールアップに含まれるわけではありません。まだ含まれていない残りの .NET Framework 3.5 用の更新プログラムは、徐々にロールアップに組み込まれていく予定です。以前公開された.NET Framework 3.5 用の更新プログラムのすべてが月例のロールアップに含まれた時点で、ブログを通じてお知らせします。

サポートされている .NET Framework のバージョン

この新しいリリースは、サポートされているバージョンの .NET Framework に適用されます。つまり、新しい更新プログラムを利用するためにはサポートされているバージョンの .NET Framework をインストールする必要があります。このブログ執筆時のサポートされているバージョンは、以下のとおりです。

• .NET Framework 3.5
• .NET Framework 4.5.2、またはそれ以降

サポートされている OS のバージョン

この新しいリリースは Windows Vista SP2、Windows 7 SP1、Windows 8.1、Windows Server 2008 SP2、Windows Server 2008 R2、Windows Server 2012 および Windows Server 2012 R2 に適用されます。

Windows 10 に関しては、同じ内容の .NET Framework 用のセキュリティおよび品質更新プログラムが月例の Windows Update に含まれています。

頻度

更新プログラムは毎月出荷する予定ですが、変更があった場合にのみ公開します。また、一部の .NET Framework のバージョンおよび、または Windows のバージョンにのみ適用される変更もあります。

.NET Framework の更新について

更新プログラムにはパッチレベルの変更が含まれています。更新プログラムを適用することで、使用中のコンピューターにインストールされている .NET Framework を新しいバージョンにアップグレードすることはありません。たとえば、コンピューターに .NET Framework 4.5.2 がインストールされていて 4.6.2 がインストールされていない場合、更新プログラムを適用しても .NET Framework 4.6.2 がインストールされることはありません。新しいバージョンの .NET Framework にアップグレードしたい場合は、個別にインストールする必要があります。

インストールについて

オペレーティング システムごとに 1 つのアイテムが表示されます。

セキュリティおよび品質ロールアップ (Windows Server 2008 SP2 上)

セキュリティのみの更新プログラム (Windows Server 2008 SP2 上)

このリリースのアンインストール エクスペリエンスについて、たくさんの質問を受けました。上記のセキュリティおよび品質ロールアップは、1 つのインストールとして表示されています。この更新プログラムを適用した後、特定のバージョンの .NET Framework のリリースを削除することが可能です。

たとえば、.NET Framework 3.5 および 4.5.2 がインストールされているコンピューターにセキュリティおよび品質ロールアップを適用した後、.NET Framework 4.5.2 用のセキュリティおよび品質ロールアップを残したまま .NET Framework 3.5 用のセキュリティおよび品質ロールアップをアンインストールすることができます。その逆も可能です。

以下の画像では [プログラムの追加と削除] ダイアログ ボックスの [更新プログラムをアンインストールする] に、特定のバージョンの更新プログラムが表示されていることがわかります。

インストール済みのセキュリティのみの更新プログラム (Windows Server 2008 SP2 上)

終わりに

新しいモデルへの変更により、最新の .NET Framework の更新プログラムをよりシンプルな方法で入手することができます。大多数のユーザー向けの「セキュリティおよび品質ロールアップ」、そして修正プログラムの適用をコントロールし、幅広く公開される前に変更をプレビューしたいユーザー向けの「セキュリティのみの更新プログラム」および「品質ロールアップ プレビュー」という 3 種類の選択肢を用意しています。

多くのユーザーに対しては、毎月 Windows Update を通じて最新の変更が提供されるので、従来のエクスペリエンスとほとんど変わりません。セキュリティのみの更新プログラムおよび、または品質ロールアップ プレビューの利用を検討しているお客様は十分に計画を立ててから移行してください。

この新しいモデルは、Windows のサービス モデルの変更に従うものです。Windows 10 に関しては、.NET Framework の修正は Windows の更新プログラムに含まれています。

このリリースの使い方や、お客様の環境におけるアプローチ方法についてのフィードバックをお聞かせください。今後も、どのパッケージが公開され、お客様の環境に適用可能かどうかを判断できるよう、ブログで具体的な更新プログラムについてお知らせします。

(この記事は 2016 年 9 月 26 日に Office Blogs に投稿された記事 Major OneDrive updates at Ignite 2016 include SharePoint Online sync preview の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

OneDrive と SharePoint を組み合わせると、ファイルの保存や編集がより簡単で便利になります。マイクロソフトが最近発表した Office 365 ファイル管理機能を強化するという構想には、組織の内外から簡単にアクセスできるファイル共有機能、OneDrive から SharePoint に直接ファイルをコピーする機能、iOS デバイスからすべての Office 365 ファイルへのモバイル アク セス、Microsoft Graph を活用して関連性のあるファイルや頻繁に使用されているファイルを提示する革新的な [Discover] ビューなどが盛り込まれていました。

この記事では、今回 Ignite にて新たに発表された同期、ブラウザー、モバイル、および IT 関連の新機能をご紹介します。

同期関連では以下の新機能が追加されます。

• SharePoint Online ドキュメント ライブラリと OneDrive 共有フォルダーの同期が可能になりました (プレビュー版提供中)
• OneDrive 同期クライアントに “アクティビティ センター” が追加され、同期やファイル利用の状況をひとめで確認できるようになりました (プレビュー版提供中)

ブラウザー関連では以下の新機能が追加されます。

• リッチなサムネイルとプレビューが新たに 20 種類以上のファイル形式に対応します (2016 年末までにロールアウト)
• OneDrive ブラウザー クライアントから OneDrive と SharePoint Online のファイルにアクセスして編集することが可能になります (2016 年末までにロールアウト)
• 複数のファイルを .zip ファイルに圧縮してまとめてダウンロードできるようになります (2016 年末までにロールアウト)

モバイル関連では次の新機能が追加されます。

• OneDrive のファイルが他のユーザーから共有されたときに iOS および Android デバイスに通知が送信されるようになりました (現在提供中)
• Android の OneDrive アプリから SharePoint Online ファイルへのアクセスが可能になりました (現在提供中)
• Android の OneDrive アプリで複数のページをまとめてスキャンできるようになりました (現在提供中)
• OneDrive にある自分のファイルを見つけて閲覧したユーザー数の履歴を iOS の OneDrive アプリで確認できるようになりました (現在提供中)

IT 関連では次の新機能が追加されます。

• Office 2016 との連携が強化されました (初回リリースにて提供)
• Office 365 での OneDrive ユーザーの管理がよりシンプルで柔軟になりました (初回リリースにて提供)
• Office 365 に OneDrive 専用の管理コンソールが追加されます (2016 年末までにロールアウト)

強力な同期オプションの追加により、外出先でのファイル操作がさらに便利に

これまで、マイクロソフトは Office 365 のあらゆるファイルを OneDrive や SharePoint と同期する新機能の計画をお伝えしてきました。このたび、Windows PC と Mac の両方において、待望の新機能のパブリック プレビュー版がリリースされました。

SharePoint との同期機能は昨年リリースされた OneDrive 同期クライアントに追加される予定で、高水準の信頼性、パフォーマンス、操作性に加え、特定のフォルダーを選択してオフラインで利用できる柔軟性も兼ね備えています。

これにより、Office 365 ファイルをオフラインで簡単に利用できるようになります。従来の同期クライアント (groove.exe) からのアップグレードもシームレスに行われます。

また、共有フォルダーとの同期も今回のプレビュー版に盛り込まれた強力な新機能の 1 つです。組織内の同僚から OneDrive フォルダーが共有された場合は、そのフォルダーをオフラインで利用するかどうかを選択できます。また、同僚から共有されたフォルダーの容量は自身のストレージ使用量には加算されません。

さらに、現在はアクティビティ センターのロールアウトを進めており、同期クライアントの状況をいっそう簡単に把握できるようになる予定です。同期の対象として選択したフォルダー内でファイルの追加、削除、変更などの操作が行われるとアクティビティ センターに操作履歴が表示されるので、最近の操作や現在の同期状況を簡単に把握することができます。

プレビュー版のダウンロードとセットアップの方法については、こちら (英語) をご覧ください。

進化したプレビューとサムネイルでファイルの内容をすばやく確認

OneDrive と Office Online の連携が強化され、どのブラウザーからでもファイルの表示、編集、作成が可能になります。また、ダウンロードせずにブラウザーで直接表示できるファイルの種類が増加します。これにより、ビジネスで広く利用されているファイル形式であれば、リッチなプレビューを確認しながら内容をすばやく把握できるようになります。たとえば、Illustrator (.ai)、Photoshop (.psd)、Encapsulated PostScript (.eps) などの Adobe ファイルを、OneDrive 内で直接プレビューすることができます。また、電子メール (.msg と .eml) や、ほぼすべての写真ファイル (多くの RAW 形式を含む)、ストリーミング動画もサポートされます。さらに、フォルダーの内容をタイル形式で表示した場合には、サポートされている大部分の形式のファイルについて、高解像度のサムネイルが表示されます。ブラウザー関連の機能強化はこれで終わりではなく、今後も新しいファイル形式をサポートし、プレビュー機能をますます強化し、サムネイルの対応をさらに充実させていく予定です。

OneDrive ブラウザー環境を通じてすべての Office 365 ファイルにアクセス

マイクロソフトのミッションは、どこにいても Office 365 ファイルを操作できるようにすることです。間もなく、OneDrive ブラウザーの更新プログラムがリリースされ、SharePoint Online で所有またはフォローしているすべてのファイルとフォルダーにブラウザーからアクセスし、編集や共有を行えるようになります。この更新は数か月以内に初回リリース プログラム参加者の皆様を対象としてロールアウトされ、2017 年第 1 四半期にはすべてのお客様にロールアウトされる予定です。同時に、モバイル アプリのエクスペリエンスや同期機能も統一され、必要な Office 365 ファイルをどこからでも同じ方法で操作することが可能になります。これにより、作業する環境がブラウザーか、Windows PC か、Mac か、マイクロソフト アプリがインストールされたデバイスかを問わず、自身が所有するすべての Office 365 ファイルへのアクセス、共有、編集、共同作業を OneDrive だけで行えるようになります。

複数のファイルを .zip ファイルに圧縮してまとめてダウンロード

お客様からのご要望にお応えして、OneDrive ブラウザー環境に新しい機能をもう 1 つ追加しました。複数のファイルやフォルダーを選択してダウンロードする際、1 つの .zip ファイルに圧縮する機能です。

モバイル通知で最新情報を入手

iOS および Android のユーザー向けに、同僚からファイルが共有されたときに通知を配信する機能が追加されました。通知から直接ファイルを開くこともできます。これにより、同僚と共有している企画書の更新に着手してよいのか、明日のプレゼンテーションの最終レビューを進めてもよいのかといった確認を電子メールで行う必要がなくなります。この通知機能は今後 Android と Windows にも展開され、共有だけでなくその他のファイル操作に関する通知も配信されるようになります。

複数の写真をまとめてスキャン

Android 向けに今年リリースされたスキャン機能では、写真を 1 枚ずつ撮影して PDF に変換し、OneDrive にアップロードすることができます。この機能がさらに進化し、複数の写真をまとめて 1 つの PDF ファイルに変換することが可能になりました。これにより、複数のページにわたる領収書や複数のホワイトボードに書かれた膨大なメモをスキャンして 1 つの PDF にまとめ、OneDrive にアップロードして保存することが可能になります。

この機能は数週間以内に iOS にロールアウトされます。

自身の作業成果の認知度と影響度を把握

OneDrive から SharePoint にファイルをコピーすると (これは最近リリースされた機能です)、チーム メンバー全員がそのファイルを見つけてアクセスすることが可能になります。今年 5 月、マイクロソフトはファイルの認知度を把握する機能の開発に着手したことを発表しましたが、本日より、ファイルを見つけて閲覧したユーザーの数を時系列で表示する機能の提供を iOS 向けに開始しました。これにより、自身の作業成果の影響度を簡単に把握することが可能になります。この機能は今後の更新で Android と Windows にも展開される予定です。

Office 2016 との連携が強化され、他のユーザーとの共同作業がより効率的に

マイクロソフトでは、Microsoft Office と OneDrive をどの環境で使用しているかを問わず同じ作業を行えるよう、真の意味でシームレスな Office との連携に向けて開発を続けています。Office 2016 リボンの右上に現在ファイルを編集しているユーザーが表示され、ここから Skype for Business を起動してリアルタイムで会話することが可能になりました。また、ファイルを共有したり、ファイル操作の履歴を表示したりすることもできます。Office アプリを閉じることなく他のユーザーとファイルを共有し、ファイルに対して現在どのような操作が行われているかを把握できるため、作業効率の大幅な向上が期待できます。

また、[File] タブをクリックしてファイルを開く際に、OneDrive と SharePoint Online で最近アクセスされたファイルの一覧だけでなく、他のユーザーから最近共有されたファイルの一覧も表示されるようになりました。これにより、どのデバイスからでも作業中のすべてのファイルにアクセスできるようになりました。これも、作業効率の向上につながる OneDrive と SharePoint ならではの特筆すべき機能です。

IT プロフェッショナル向けの機能強化により OneDrive のセキュリティと管理性がさらに向上

本日から 2016 年末にかけて、OneDrive のセキュリティと管理性を強化する IT プロフェッショナル向けの新機能が続々リリースされます。Office 365 ユーザー管理コンソールから直接 OneDrive ユーザーを個別に管理する機能もその 1 つです。この管理コンソールでは、ユーザーごとにストレージ クォータや外部共有の設定を行ったり、間違った場所にファイルを保存してしまったユーザーや、間違ったファイルを共有してしまったユーザーをサポートしたりすることが可能です。また、デバイス紛失などの緊急時には、該当するユーザーをすべてのデバイスで OneDrive からサインアウトさせることもできます。さらに、退職した従業員の OneDrive を引き継いで重要なファイルを別の場所にコピーしたり移動したりすることもできます。この機能は今年前半にリリースされた機能をさらに進化させたもので、削除されたユーザーの OneDrive にあるファイルを最長 10 年間保存できるため、重要なファイルが失われる心配がなくなります。マイクロソフトでは、ユーザー別の設定と管理に関連する機能を今後も引き続き強化してまいります。

また、Office 365 管理センターに OneDrive 専用の管理コンソールが追加されて、OneDrive 固有の設定を 1 箇所に表示して構成できるようになるため、従来 PowerShell で行っていた管理作業を Office 365 で行えるようになります。この新機能により、組織での OneDrive の管理がよりシンプルで先進的なものになり、管理作業の効率が向上し、ユーザーからのリクエストに迅速に対応することが可能になります。

シンプルで強力なファイル共有の未来を先取り

Office 365 ユーザーの皆様にご利用いただける、シンプルで強力なファイル共有を実現する数々のイノベーションをお届けします。OneDrive を使えば、個人の OneDrive、SharePoint チーム サイト、Office 365 グループに保存されているすべてのファイルをシンプルかつ一貫した方法で操作することができます。マイクロソフトでは今後も、盤石の同期機能、ブラウザー環境のさらなる充実、高い評価を頂いているモバイル アプリ、Microsoft Office との連携強化を進めていく予定です。なお、これらの成果は Windows PC や Mac を含むすべてのデバイスでご利用いただけるようになる予定です。マイクロソフトでは今後もコンテンツの検索機能や自身の作業成果の影響度を把握するための機能を強化することにより、生産性の向上につながる革新的なインテリジェンスをユーザーの皆様に提供できるように引き続き努めてまいります。これらの新機能を支えるのは、セキュリティ、コンプライアンス、管理性にかかわる Office 365 ならではの機能です。

いますぐ新しい更新プログラムをお試しください。また、ご意見やご要望は マイクロソフト テクニカル コミュニティ (英語) および UserVoice (英語) までお寄せください。今後も OneDrive と SharePoint の機能強化に取り組んでまいりますので、ぜひご期待ください。

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

Im Rahmen der Microsoft Ignite Konferenz (https://ignite.microsoft.com) wurde die Technical Preview 2 (TP2) von Azure Stack angekündigt. Wie die vorherige TP1 Version steht auch die TP2 wieder öffentlich zur Verfügung. Somit kann jeder mit Interesse und geeigneter Hardware in die Testphase einsteigen. Wie vorher ist auch diese Version nicht für den produktiven Einsatz vorgesehen.

Die öffentliche TP2 von Azure Stack ist weiterhin ein Single Server Proof of Concept, daher entsprechen die Hardware Anforderungen grundsätzlich der TP1. Auch in dieser Vorabversion wird ein Azure Active Directory für die Authentifizierung verwendet, daher bitte daran denken dies vorher anzulegen.

Die erste Finale Version von Azure Stack ist für Mitte 2017 (Kalenderjahr) angekündigt. Wichtig, diese wird ausschließlich als integriertes System über entsprechende Hardware Partner zur Verfügung gestellt. Auf der Microsoft Ignite haben die Partner Dell, HPE und Lenovo erste Einblicke gegeben.

Hier eine Übersicht, wie es weitergeht:

Nachfolgend habe ich die wichtigsten Informationen für den Start eines Proof of Concept zusammengestellt und werde diese bei Bedarf aktualisieren.

Vorrausetzungen für Azure Stack TP2 (Hardware, Betriebssystem, Azure Active Directory, Netzwerk, Internet Verbindung)

https://azure.microsoft.com/en-us/documentation/articles/azure-stack-deploy/

Tool zum Prüfen ob Voraussetzungen erfüllt sind

https://gallery.technet.microsoft.com/Deployment-Checker-for-50e0f51b

Download der TP2

https://azure.microsoft.com/en-us/overview/azure-stack/try/?v=try

Installationsanleitung

https://azure.microsoft.com/en-us/documentation/articles/azure-stack-run-powershell-script/

Neustart der Installation bei Fehlern

https://azure.microsoft.com/en-us/documentation/articles/azure-stack-rerun-deploy/

Azure Stack Dokumentation

https://azure.microsoft.com/en-us/documentation/azure-stack/

Azure Stack Vorträge auf der Microsoft Ignite Konferenz

https://azure.microsoft.com/en-us/blog/microsoft-ignite-azure-stack-technical-sessions/

Azure Resource Manager White Paper

http://download.microsoft.com/download/E/A/4/EA4017B5-F2ED-449A-897E-BD92E42479CE/Getting_Started_With_Azure_Resource_Manager_white_paper_EN_US.pdf

Azure Resource Manager Templates für Azure Stack

http://aka.ms/AzureStackGitHub

Viel Erfolg!!

Hi!

Linda Taylor here, Senior Escalation Engineer in the Directory Services space.

I have spent the last month working with customers worldwide who experienced password change failures after installing the updates under Ms16-101 security bulletin KB’s (listed below), as well as working with the product group in getting those addressed and documented in the public KB articles under the known issues section. It has been busy!

In this post I will aim to provide you with a quick “cheat sheet” of known issues and needed actions as well as ideas and troubleshooting techniques to get there.

Let’s start by understanding the changes.

The following 6 articles describe the changes in MS16-101 as well as a list of Known issues. If you have not yet applied MS16-101 I would strongly recommend reading these and understanding how they may affect you.

        3176492 Cumulative update for Windows 10: August 9, 2016
        3176493 Cumulative update for Windows 10 Version 1511: August 9, 2016
        3176495 Cumulative update for Windows 10 Version 1607: August 9, 2016
        3178465 MS16-101: Security update for Windows authentication methods: August 9, 2016
        3167679 MS16-101: Description of the security update for Windows authentication methods: August 9, 2016
        3177108 MS16-101: Description of the security update for Windows authentication methods: August 9, 2016

The good news is that this month’s updates address some of the known issues with MS16-101.

The bad news is that not all the issues are caused by some code defect in MS16-101 and in some cases the right solution is to make your environment more secure by ensuring that the password change can happen over Kerberos and does not need to fall back to NTLM. That may include opening TCP ports used by Kerberos, fixing other Kerberos problems like missing SPN’s or changing your application code to pass in a valid domain name.

Let’s start with the basics…

Symptoms:

After applying MS16-101 fixes listed above, password changes may fail with the error code

“The system detected a possible attempt to compromise security. Please make sure that you can contact the server that authenticated you.”
Or
“The system cannot contact a domain controller to service the authentication request. Please try again later.”

This text maps to the error codes below:

Question: What does MS16-101 do and why would password changes fail after installing it?

Answer: As documented in the listed KB articles, the security updates that are provided in MS16-101 disable the ability of the Microsoft Negotiate SSP to fall back to NTLM for password change operations in the case where Kerberos fails with the STATUS_NO_LOGON_SERVERS (0xc000005e) error code.
In this situation, the password change will now fail (post MS16-101) with the above mentioned error codes (ERROR_DOWNGRADE_DETECTED / STATUS_DOWNGRADE_DETECTED).
Important: Password RESET is not affected by MS16-101 at all in any scenario. Only password change using the Negotiate package is affected.

So, now you understand the change, let’s look at the known issues and learn how to best identify and resolve those.

Summary and Cheat Sheet

To make it easier to follow I have matched the ordering of known issues in this post with the public KB articles above.

First, when troubleshooting a failed password change post MS16-101 you will need to understand HOW and WHERE the password change is happening and if it is for a domain account or a local account. Here is a cheat sheet.

Summary of SCENARIO’s and a quick reference table of actions needed.

Table of Fixes for known issues above release 2016.10.11, taken from MS16-101 Security Bulletin:

Troubleshooting

As I mentioned, this post is intended to support the documentation of the known issues in the Ms16-101 KB articles and provide help and guidance for troubleshooting. It should help you identify which known issue you are experiencing as well as provide resolution suggestions for each case.

I have also included a troubleshooting walkthrough of some of the more complex example cases. We will start with the problem definition, and then look at the available logs and tools to identify a suitable resolution. The idea is to teach “how to fish” because there can be many different scenario’s and hopefully you can apply these techniques and use the log files documented here to help resolve the issues when needed.

Once you know the scenario that you are using for the password change the next step is usually to collect some data on the server or client where the password change is occuring. For example if you have a web server running a password change application and doing password changes on behalf of users, you will need to collect the logs there. If in doubt collect the logs from all involved machines and then look for the right one doing the password change using the snippets in the examples. Here are the helpful logs.

DATA COLLECTION

The same logs will help in all the scenario’s.

LOGS

1. SPENGO debug log/ LSASS.log

To enable this log run the following commands from an elevated admin CMD prompt to set the below registry keys:

• This will log Negotiate debug output to the %windir%system32lsass.log.
• There is no need for reboot. The log is effective immediately.
• Lsass.log is a text file that is easy to read with a text editor such as Wordpad.

2. Netlogon.log:

This log has been around for many years and is useful for troubleshooting DC LOCATOR traffic. It can be used together with a network trace to understand why the STATUS_NO_LOGON_SERVERS is being returned for the Kerberos password change attempt.

· To enable Netlogon debug logging run the following command from an elevated CMD prompt:

            nltest /dbflag:0x26FFFFFF

· The resulting log is found in %windir%debugnetlogon.log & netlogon.bak

· There is no need for reboot. The log is effective immediately. See also 109626 Enabling debug logging for the Net Logon service

· The Netlogon.log (and Netlogon.bak) is a text file.

           Open the log with any text editor (I like good old Notepad.exe)

3. Collect a Network trace during the password change issue using the tool of your choice.

Scenario’s, Explanations and Walkthrough’s:

When reading this you should keep in mind that you may be seeing more than one scenario. The best thing to do is to start with one, fix that and see if there are any other problems left.

1. Domain password change fails via CTRL+ALT+DEL

This is most likely a Kerberos DC locator failure of some kind where the password changes were relying on NTLM before installing MS16-101 and are now failing. This is the simplest and easiest case to resolve using basic Kerberos troubleshooting methods.

Solution: Fix Kerberos.

Some tips from cases which we saw:

1. Use the Network trace to identify if the necessary communication ports are open. This was quite a common issue. So start by checking this.

         In order for Kerberos password changes to work communication on TCP port 464 needs to be open between the client doing the
         password change and the domain controller.

Note on RODC: Read-only domain controllers (RODCs) can service password changes if the user is allowed by the RODCs password replication policy. Users who are not allowed by the RODC password policy require network connectivity to a read/write domain controller (RWDC) in the user account domain to be able to change the password.

           To check whether TCP port 464 is open, follow these steps (also documented in KB3167679):

             a. Create an equivalent display filter for your network monitor parser. For example:

                            ipv4.address== <ip address of client> && tcp.port==464

             b. In the results, look for the “TCP:[SynReTransmit” frame.

If you find these, then investigate firewall and open ports. It is often useful to take a simultaneous trace from the client and the domain controller and check if the packets are arriving at the other end.

2. Make sure that the target Kerberos names are valid.

• IP addresses are not valid Kerberos names
• Kerberos supports short names and fully qualified domain names. Like CONTOSO or Contoso.com

3. Make sure that service principal names (SPNs) are registered correctly.

For more information on troubleshooting Kerberos see https://blogs.technet.microsoft.com/askds/2008/05/14/troubleshooting-kerberos-authentication-problems-name-resolution-issues/ or https://technet.microsoft.com/en-us/library/cc728430(v=ws.10).aspx

2. Domain password change fails via application code with an INCORRECT/UNEXPECTED Error code when a password which does not meet password complexity is entered.

For example, before installing MS16-101, such password change may have returned a status like STATUS_PASSWORD_RESTRICTION. After installing Ms16-101 it returns STATUS_DOWNGRADE_DETECTED causing your application to behave in an expected way or even crash.

Note: In this scenario, password change succeeds when correct new password is entered that complies with the password policy.

Cause:

This issue is caused by a code defect in ADSI whereby the status returned from Kerberos was not returned to the user by ADSI correctly.
Here is a more detailed explanation of this one for the geek in you:

Before MS16-101 behavior:

           1. An application calls ChangePassword method from using the ADSI LDAP provider.
           Setting and changing passwords with the ADSI LDAP Provider is documented here.
           Under the hood this calls Negotiate/Kerberos to change the password using a valid realm name.
           Kerberos returns STATUS_PASSWORD_RESTRICTION or Other failure code.

          2. A 2nd changepassword call is made via NetUserChangePassword API with an intentional realmname as the <dcname> which uses
           Negotiate and will retry Kerberos. Kerberos fails with STATUS_NO_LOGON_SERVERS because a DC name is not a valid realm name.

         3.Negotiate then retries over NTLM which succeeds or returns the same previous failure status.

The password change fails if a bad password was entered and the NTLM error code is returned back to the application. If a valid password was entered, everything works because the 1st change password call passes in a good name and if Kerberos works, the password change operation succeeds and you never enter into step 3.

Post MS16-101 behavior /why it fails with MS16-101 installed:

         1. An application calls ChangePassword method from using the ADSI LDAP provider. This calls Negotiate for the password change with
          a valid realm name.
         Kerberos returns STATUS_PASSWORD_RESTRICTION or Other failure code.

         2. A 2nd ChangePassword call is made via NetUserChangePassword with a <dcname> as realm name which fails over Kerberos with
         STATUS_NO_LOGON_SERVERS which triggers NTLM fallback.

          3. Because NTLM fallback is blocked on MS16-101, Error STATUS_DOWNGRADE_DETECTED is returned to the calling app.

Solution: Easy. Install the October update which will fix this issue. The fix lies in adsmsext.dll included in the October updates.

Again, here are the updates you need to install, Taken from MS16-101 Security Bulletin:

3.Local user account password change fails via CTRL+ALT+DEL or application code.

Installing October updates above should also resolve this.

MS16-101 had a defect where Negotiate did not correctly determine that the password change was local and would try to find a DC using the local machine as the domain name.

This failed and NTLM fallback was no longer allowed post MS16-101. Therefore, the password changes failed with STATUS_DOWNGRADE_DETECTED.

Example:

One such scenario which I saw where password changes of local user accounts via ctrl+alt+delete failed with the message “The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.” Was when you have the following group policy set and you try to change a password of a local account:

Cause: In this case, post MS16-101 Negotiate incorrectly determined that the account is not local and tried to discover a DC using \<machinename> as the domain and failed. This caused the password change to fail with the STATUS_DOWNGRADE_DETECTED error.

Solution: Install October fixes listed in the table at the top of this post.

4.Passwords for disabled and locked out user accounts cannot be changed using Negotiate method.

MS16-101 purposely disabled changing the password of locked-out or disabled user account passwords via Negotiate by design.

Important: Password Reset is not affected by MS16-101 at all in any scenario. Only password change. Therefore, any application which is doing a password Reset will be unaffected by Ms16-101.

Another important thing to note is that MS16-101 only affects applications using Negotiate. Therefore, it is possible to change locked-out and disabled account password using other method’s such as LDAPs.

For example, the PowerShell cmdlet Set-ADAccountPassword will continue to work for locked out and disabled account password changes as it does not use Negotiate.

5. Troubleshooting Domain password change failure via application code when a good password is entered.

This is one of the most difficult scenarios to identify and troubleshoot. And therefore I have provided a more detailed example here including sample code, the cause and solution.

In summary, the solution for these cases is almost always to correct the application code which maybe passing in an invalid domain name such that Kerberos fails with STATUS_NO_LOGON_SERVERS.

Scenario:

An application is using system.directoryservices.accountmanagement namespace to change a users password.
https://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement(v=vs.110).aspx

After installing Ms16-101 password changes fail with STATUS_DOWNGRADE_DETECTED. Example .NET failing code snippet using PowerShell which worked before MS16-101:

<snip>

Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$ct = [System.DirectoryServices.AccountManagement.ContextType]::Domain
$ctoptions = [System.DirectoryServices.AccountManagement.ContextOptions]::SimpleBind -bor [System.DirectoryServices.AccountManagement.ContextOptions]::ServerBind
$pc = New-Object System.DirectoryServices.AccountManagement.PrincipalContext($ct, “contoso.com”,”OU=Accounts,DC=Contoso,DC=Com”, ,$ctoptions)
$idType = [System.DirectoryServices.AccountManagement.IdentityType]::SamAccountName  
$up = [System.DirectoryServices.AccountManagement.UserPrincipal]::FindByIdentity($pc,$idType, “TestUser”)
$up.ChangePassword(“oldPassword!123”, “newPassword!123”)

<snip>

Data Analysis

There are 2 possibilities here:
(a) The application code is passing an incorrect domain name parameter causing Kerberos password change to fail to locate a DC.
(b)  Application code is good and Kerberos password change fails for other reason like blocked port or DNS issue or missing SPN.

Let’s start with (a) The application code is passing an incorrect domain name/parameter causing Kerberos password change to fail to locate a DC.

(a) Data Analysis Walkthrough Example based on a real case:

1. Start with Lsass.log (SPNEGO trace)

If you are troubleshooting a password change failure after MS16-101 look for the following text in Lsass.log to indicate that Kerberos failed and NTLM fallback was forbidden by Ms16-101:

Failing Example:

[ 9/13 10:23:36] 492.2448> SPM-WAPI: [11b0.1014] Dispatching API (Message 0)
[ 9/13 10:23:36] 492.2448> SPM-Trace: [11b0] LpcDispatch: dispatching ChangeAccountPassword (1a)
[ 9/13 10:23:36] 492.2448> SPM-Trace: [11b0] LpcChangeAccountPassword()
[ 9/13 10:23:36] 492.2448> SPM-Helpers: [11b0] LsapCopyFromClient(0000005EAB78C9D8, 000000DA664CE5E0, 16) = 0
[ 9/13 10:23:36] 492.2448> SPM-Neg: NegChangeAccountPassword:
[ 9/13 10:23:36] 492.2448> SPM-Neg: NegChangeAccountPassword, attempting: NegoExtender
[ 9/13 10:23:36] 492.2448> SPM-Neg: NegChangeAccountPassword, attempting: Kerberos
[ 9/13 10:23:36] 492.2448> SPM-Warning: Failed to change password for account Test: 0xc000005e
[ 9/13 10:23:36] 492.2448> SPM-Neg: NegChangeAccountPassword, attempting: NTLM
[ 9/13 10:23:36] 492.2448> SPM-Neg: NegChangeAccountPassword, NTLM failed: not allowed to change domain passwords
[ 9/13 10:23:36] 492.2448> SPM-Neg: NegChangeAccountPassword, returning: 0xc0000388

• 0xc000005E is STATUS_NO_LOGON_SERVERS
  0xc0000388 is STATUS_DOWNGRADE_DETECTED

If you see this, it means Kerberos failed to locate a Domain Controller in the domain and fallback to NTLM is not allowed by Ms16-101. Next you should look at the Netlogon.log and the Network trace to understand why.

2. Network trace

Look at the network trace and filter the traffic based on the client IP, DNS and any authentication related traffic.
You may see the client is requesting a Kerberos ticket using an invalid SPN like:

So here the client tried to get a ticket for this ldapContoso.com SPN and failed with KDC_ERR_S_PRINCIPAL_UNKNOWN because this SPN is not registered anywhere.

• This is expected. A valid LDAP SPN is example like ldapDC1.contoso.com

Next let’s check the Netlogon.log

3. Netlogon.log:

Open the log with any text editor (I like good old Notepad.exe) and check the following:

• Is a valid domain name being passed to DC locator?

Invalid names such as \servername.contoso.com or IP address \x.y.x.w will cause dclocator to fail and thus Kerberos password change to return STATUS_NO_LOGON_SERVERS. Once that happens NTLM fall back is not allowed and you get a failed password change.

If you find this issue examine the application code and make necessary changes to ensure correct domain name format is being passed to the ChangePassword API that is being used.

Example of failure in Netlogon.log:

[MISC] [PID] DsGetDcName function called: client PID=1234, Dom:\contoso.com Acct:(null) Flags: IP KDC
[MISC] [PID] DsGetDcName function returns 1212 (client PID=1234): Dom:\contoso.com Acct:(null) Flags: IP KDC

\contoso.com is not a valid domain name. (contoso.com is a valid domain name)

This Error translates to:

So what happened here?

The application code passed an invalid TargetName to kerberos. It used the domain name as a server name and so we see the SPN of LDAPcontoso.com.

The client tried to get a ticket for this SPN and failed with KDC_ERR_S_PRINCIPAL_UNKNOWN because this SPN is not registered anywhere. As Noted: this is expected. A valid LDAP SPN is example like ldapDC1.contoso.com.

The application code then tried the password change again and passed in \contoso.com as a domain name for the password change. Anything beginning with \ as domain name is not valid. IP address is not valid. So DCLOCATOR will fail to locate a DC when given this domain name. We can see this in the Netlogon.log and the Network trace.

Conclusion and Solution

If the domain name is invalid here, examine the code snippet which is doing the password change to understand why the wrong name is passed in.

The fix in these cases will be to change the code to ensure a valid domain name is passed to Kerberos to allow the password change to successfully happen over Kerberos and not NTLM. NTLM is not secure. If Kerberos is possible, it should be the protocol used.

SOLUTION

The solution here was to remove “ContextOptions.ServerBind |  ContextOptions.SimpleBind ” and allow the code to use the default (Negotiate). Note, because we were using a domain context but ServerBind this caused the issue. Negotiate with Domain context is the option that works and is successfully able to use kerberos.

Working code:

<snip>
Add-Type -AssemblyName System.DirectoryServices.AccountManagement
$ct = [System.DirectoryServices.AccountManagement.ContextType]::Domain
$pc = New-Object System.DirectoryServices.AccountManagement.PrincipalContext($ct, “contoso.com”,”OU=Accounts,DC=Contoso,DC=Com”)
$idType = [System.DirectoryServices.AccountManagement.IdentityType]::SamAccountName  
$up = [System.DirectoryServices.AccountManagement.UserPrincipal]::FindByIdentity($pc,$idType, “TestUser”)
$up.ChangePassword(“oldPassword!123”, “newPassword!123”)
<snip>

Why does this code work before MS16-101 and fail after?

ContextOptions are documented here: https://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.contextoptions(v=vs.110).aspx

Specifically: “This parameter specifies the options that are used for binding to the server. The application can set multiple options that are linked with a bitwise OR operation. “

Passing in a domain name such as contoso.com with the ContextOptions ServerBind or SimpleBind causes the client to attempt to use an SPN like ldapcontoso.com because it expects the name which is passed in to be a ServerName.

This is not a valid SPN and does not exist, therefore this will fail and as a result Kerberos will fail with STATUS_NO_LOGON_SERVERS.
Before MS16-101, in this scenario, the Negotiate package would fall back to NTLM, attempt the password change using NTLM and succeed.
Post MS16-101 this fall back is not allowed and Kerberos is enforced.

(b) If Application Code is good but Kerberos fails to locate a DC for other reason

If you see a correct domain name and SPN’s in the above logs, then the issue is that kerberos fails for some other reason such as blocked TCP ports. In this case revert to Scenario 1 to troubleshoot why Kerberos failed to locate a Domain Controller.

There is a chance that you may also have both (a) and (b). Traces and logs are the best tools to identify.

Scenario6: After you install MS 16-101 update, you may encounter 0xC0000022 NTLM authentication errors.

I will not go into detail of this scenario as it is well described in the KB article KB3195799 NTLM authentication fails with 0xC0000022 error for Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 after update is applied.

That’s all for today! I hope you find this useful. I will update this post if any new information arises.

Linda Taylor | Senior Escalation Engineer | Windows Directory Services
(A well established member of the content police.)

スペシャルトラックセッション紹介第 4 弾です。

日本マイクロソフトの エバンジェリストである西脇のセッションのスペシャルゲストが決定しました。
そして、どんなセッションになるのか、西脇にこっそり聞いたので本ブログでご紹介します！

今回、日本のクラウド市場を黎明期から立ち上げてきたお二人である、元 AWS 担当 小島 英揮 氏、元マイクロソフト 砂金 信一郎  氏にご登壇頂きます。

そして、日本では本格的に立ち上がっていなかったクラウドを Azure と AWS のそれぞれの世界でリードしてきたお二人とともに 「IT キャリアの多様性と未来」をテーマに Tech Summit 参加の皆様に特別なセッションをお届けします！

今回はデモなどではなく、3 名ならではの話が繰り広げられます。

そして、気になるトークはの内容は・・？

「どうやってクラウドを立ち上げたのか」

「コミュニティの存在とビジネスを軌道に乗せるコツ」

「クラウドビジネスのぶっちゃけ話」

「で、これから何が流行るのか？」

「IT  に携わる人のキャリアパスは？」

などなど、聞き逃したくない、ちょっとドキドキする本音トークを、西脇だからこそ、しっかりと引き出します。

また、今回の Tech Summit でも 西脇セッションで評判の Twitterリアルタイム連動を行う予定とのこと！

（なんだろうと思った方はぜひご来場ください！）

このワクワクする瞬間をぜひ会場にてお聞き逃しなく！

【SPL005】
エバンジェリストが注目のこの人と語る IT キャリアの多様性と未来

今注目のこの人と語るセッション！、エバンジェリストが “あの元 AWS 立ち上げを支えた 小島英揮氏” と “現 LINE 株式会社で元 Microsoft エバンジェリスト 砂金信一郎氏” と語る IT キャリアの多様性と未来。私たちは何を見てどんな将来を作り上げていくべきなのか、とてもラフにとても気軽にとても楽しくお届けします。Tech Summit の最後の時間にふさわしいセッションです。

	元AWS マーケティング担当 小島 英揮 氏 Twitter -> @hide69oz
	LINE株式会社 ビジネスプラットフォーム事業室 戦略企画担当ディレクター 砂金 信一郎 氏 （元日本マイクロソフト株式会社 エバンジェリスト） Twitter ->@shin135
	日本マイクロソフト株式会社 コーポレート戦略統括本部 エバンジェリスト 西脇 資哲

———————————————————————————————————

• 最新セッションスケジュールはこちら
• Twitter：Technetj　（ハッシュタグ　#mstechsummit16）
• Facebook : Microsoft for work

———————————————————————————————————

On Tuesday, October 25, 2016, we will hold the next Cloud Adoption Advisory Board (CAAB) webinar. CAAB webinars are one hour and consist of brief presentations followed by time for open feedback.

The Skype for Business/Lync Meeting will open at 7:45 AM Pacific Daylight Time. The session will begin promptly at 8:00 AM and run to 9:00 AM. There will be time for questions during the session, and the speakers are usually available for a few minutes after the session if you have any additional questions.

Here is the agenda:

• See how to deploy AD FS infrastructure for Office 365 federated authentication in Azure with CAAB member Trevor Seward
• Get a tour of the IT Pro Cloud Essentials and IT Pro Career Center sites with Microsoft’s Mark Winters and Teresa Conte
• Get a tour of the new Microsoft Mobility and Security for Enterprise Architects poster with Brenda Carter
• Get a tour of the new Contoso in the Microsoft Cloud poster with Joe Davies
• Get a quick tour of the Office 365 and EMS test lab guide stack with Joe Davies

Let us know if you have something to present in a future CAAB webinar at CAAB@microsoft.com.

Thanks and we’ll see you on the 25th!

Note: By participating in this webinar you agree that Microsoft may record and use this session for internal purposes only.

To receive an invitation to a CAAB Webinar, you must be a CAAB member. To join the CAAB, become a member of the CAAB space in the Microsoft Tech Community and send a quick email to CAAB@microsoft.com to introduce yourself. Please feel free to include any information you want about your experience in creating cloud-based solutions with Microsoft products or areas of interest. Join now and add your voice to the cloud adoption discussion that is happening across Microsoft and the industry.

Continuing my post on Filtering files by their metadata (extended properties), and a question raised by Ankor in the comments section, I decided to quickly wrap up a new function (based on the one in the post) that simply adds the specified extended properties as new note properties to the object in the pipeline. As we would be reading only the required extended properties it would run much faster, and we could simply filter those objects later using the Where-Object (or with any other comparison statement).

The functions’ code is:

function Add-ExtendedAttribute {

   

    [CmdletBinding()]

    param(

        [Parameter(Mandatory = $true,

            ValueFromPipeline = $true,

            ValueFromPipelineByPropertyName = $true)]

        [Alias(‘FullName’, ‘PSPath’)]

        [string[]]$Path,

 

        [Parameter(Mandatory = $true)]

        [ValidateRange(0,287)]

        [int[]]$ExtendedAttributeId

 

    )

    begin {

        $oShell = New-Object -ComObject Shell.Application

    }

 

    process {

        $Path | ForEach-Object {

 

            if (Test-Path -Path $_ -PathType Leaf) {

 

                $FileItem = Get-Item -Path $_

 

                $oFolder = $oShell.Namespace($FileItem.DirectoryName)

                $oItem = $oFolder.ParseName($FileItem.Name)

 

                $ExtendedAttributeId | ForEach-Object {

 

                    $ExtPropName = $oFolder.GetDetailsOf($oFolder.Items, $_)

                    $ExtValName = $oFolder.GetDetailsOf($oItem, $_)

              

                    $params = @{

                        InputObject = $FileItem

                        MemberType = ‘NoteProperty’

                        Name = $ExtPropName

                        Value = $ExtValName

                    }

                    $FileItem = Add-Member @params -PassThru

                }

            }

            $FileItem

        }

 

    }

 

    end {

        $oShell = $null

    }

}

And you can use it:

# Rating: 19

dir -Path G:MusicaMSpecial | Add-ExtendedAttribute -ExtendedAttributeId 19 |

    Where-Object { $_.Rating -eq ‘2 Stars’ } | Copy-Item -Destination G:Temp

# Genre: 16

dir -Path G:MusicaMSpecial | Add-ExtendedAttribute -ExtendedAttributeId 16 |

    Where-Object { $_.Genre -eq ‘Rock’ } | Copy-Item -Destination G:Temp

Thank you Ankor for raising the question.

HTH,

Martin.

안녕하세요.

System Center Configuration Manager의 Lifecycle 정보를 공유드립니다.

SP2 Version으로 업데이트 되지 않은 SCCM2012 와 SP1 Version으로 업데이트 되지 않은 SCCM2012 R2의 경우 Support End Date가 도래하여 기술지원을 받으실 수 없습니다.

Microsoft의 Support Engineer를 통해서 기술지원을 받기 원하시는 사용자 및 고객께서는 Service Pack을 최신버전으로 설치하실 것을 권고드립니다.

또한 많은 알려진 이슈들이 Service Pack을 통하여 Fix 되었으므로 SCCM을 활용하시는데 많은 도움이 될 것으로 사료됩니다.

자세한 Lifecycle 정보는 아래 내용을 참고 부탁드립니다.

Microsoft Support Lifecycle – Microsoft System Center 2012 Configuration Manager

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

Microsoft Support Lifecycle – Microsoft System Center 2012 R2 Configuration Manager

감사합니다.

Those that know me know I’ve been using my free time to mess around with the idea of being able to use SCOM to help in identifying when an advanced persistent threat is active in your environment.  This is a problem that most IT organizations have given that the average attacker isn’t discovered until more than 250 days after they owned the environment. Many are never found.  Part of the problem associated with this is the massive amount of log information that needs to be parsed in order to determine an active presence in the environment. There are products you can buy such as Microsoft ATA, Splunk, or forwarding log information to Azure and using OMS.  Products like these can be expensive, but in the same token much better at log analytics than a tool like SCOM. That said, my goal is to create a poor mans solution to identifying a possible PtH in progress event. I’ll do so by seeing what is generated when I reproduce an event in my lab.  This entry will cover successful elevation attempts.  My next entry will cover my attempt to detect an attacker who is attempting to elevate with a non-DA account.

To start, I download all the necessary tools to a machine. On the same machine, I’ve made a standard domain account local admin on the machine. This is because a pass the hash attack requires having local admin rights to the machine in order to read from the LSA. To be clear, for the average attacker, getting local access to a machine, any machine, is easy to do. Typically this starts at tier 2 with a targeted fishing attack, and despite the fact that we try and educate users to never open up that email from a non-trusted source, they do it anyways, roughly to the tune of about 11% of users. I’m not bothering with this piece as I’m assuming that an attacker can get to this point fairly easily… reality is they can. 

Step 1 – switching credentials:

The first thing I’ve done is to simply execute mimikatz and launch a local command shell under a different set of creds than what I’m running under. My user account that I’m signed with with is “test”.  I have a domain admin on another session, and unbeknownst to this DA, my test account is compromised.  This is straight forward:

I grabbed the hash and launched a command shell. It appears that this generates traffic.  Using mimikatz to launch a command line under a domain admin’s credentials generates this:

Each of these items are parameterized, which makes it somewhat easy to craft a rule in SCOM. The trick is making sure that the events in question are unique to this type of an attack. If they aren’t, all I’ve done is create a whole bunch of noise that will be ignored.  As luck would have it, the LogonProcessName and LogonType fields are distinctly different from the average 4624 event in my environment.  Let’s hold on to that thought for the moment.

Step 2 – Lateral Movement:

Now, I’m going to use those credentials to hit another machine.  This is why PtH attacks are of such concern.  This is easy.  From the command prompt that opened, I simply launched a psexec from the new shell to a remote system.  My logged on user has no rights to this system.  However, I’m in.

I’d note that I’m trying this on my SCOM server, but moving to my DC in step 3 was just as easy, though it did manage to kick off my logged on user as an unexpected result.  Same command, different machine. My generic user account now owns my environment.  I found this event on my SCOM machine’s security log:

The XML view is a bit more complex as the impersonation level for whatever reason doesn’t translate properly. Instead of seeing “Impersonation” in the XML, I simply see a code (%%1833).

That’s fine.  That code unfortunately is not unique to this type of a movement. 

Step 3 – The DC:

On the DC, I see the pictures below.  The problem is that I see a bunch of these, so at this point I’m going to have to configure some sort of alert flood protection.  The other odd behavior here is that the impersonation level on the DC is set to Delegation, whereas on the member server, it was simply Impersonation.

The other part is that there isn’t much for bread crumbs. The impersonation level is “Delegation”, but this is hardly uncommon for 4624 events. It does, however, at least in my small sample limited view, appear to be unusual for a domain admin to sign on to a machine with an impersonation level of delegation.  I could be wrong, and that’s part of why I’m publishing this.  Computer accounts commonly have this type of impersonation, but not user accounts. This will (hopefully) give me something unique to create in SCOM.

Now that we can see the behavior of this attack, we can potentially monitor for it.  DISCLAIMER:  This is me in my lab. I’m writing this in part for my own benefit and in part because my lab is not a production environment. My goal here is to be able to monitor for an attack in progress, but to do so in a way that does not generate noise. I cannot emphasize enough that your organization will need a good alert management process in order to actually respond properly to these alerts. I’m hoping that some people with some better lab environments as well as a security background can potentially reproduce this as well as verify that the noise level in a quiet state is low.

So on to the rules.  I want to test this in some environments other than my lab to see if this holds up. It’s quite possible that it does not and instead either generates a lot of noise or doesn’t fire in certain circumstances.  Feel free to add comments with your own result.  The rule is straight forward.

Monitoring the DC for Step 3 related events:

Target: Active Directory 2008 DC Computers

The rule type is NT Event.  Here’s a screenshot of the parameters:

Parameter 9 is the logon type, parameter 21 is the impersonation level, and parameter 6 is specifically ignoring these events if there’s a $ symbol in them (which is true in the case of a machine account doing impersonation).  I configure alert flood via the Source Network address (parameter 19) as well as a filter to make sure it’s not catching any local authentication. I’m not sure if that’s the right answer or not, but this should keep this to one IP address. If someone is hopping from destination to destination, this would show as multiple alerts. The flip side is that if they sit on one system and hit many, it shows only one alert. I’m not sure there’s an easy way to configure alert flood for this given that this event shows up multiple times on a DC with only one login attempt.

On the same token, we can configure something similar against the server OS to capture the events seen when an account does side to side movement in a tier. If you’re forwarding security events to an event collector, we should be able to create a similar rule there.

One observation in my lab is the domain admin logons via RDP will generate this alert, while standard users via RDP do not.  As a rule, you probably shouldn’t be using a DA account for much of anything, but this can potentially generate false positives. I’d love additional feedback on this particular rule.

Monitoring the Member Servers for Lateral Walk (step 2):

Target:  Windows Server Operating System

Like the other rule, it is an alert generating NT event rule targeting the security log.

Parameter 9 is the logon type and Parameter 21 is the impersonation code.  Parameter 19 is filtering out the local IP address.  Due to noise, I had to filter out a few additional things. I excluded anything with ANONYMOUS in it as DCs see this type of logon event for the SYSTEM account under normal conditions. I also filtered by the $ character as local machine accounts authenticate in this manner. My SQL server also lit up this one due to normal traffic, as such I created an override to turn this off for the SQL computers group that is created by the SQL management pack. You must have the SQL MP installed in order to override this. Unfortunately, this means you cannot detect this condition on a SQL server.  However, we have plenty of other events to target. I also had to disable this against domain controllers for the same reason, though this wasn’t nearly as noisy. I needed to include Kerberos as RDP sessions will generate this event under an NTLM connection. As well, I configured alert suppression for this rule via parameter 19. This event appears more than once on a targeted system.

Monitoring for a credential swap (step 1):

Target:  Windows Server Operating System.

As with the other rules, we are targeting the security log.

Parameter 9 is logon type.  Parameter 10 is the process name.  Parameter 11 is the authentication package. 

The end result at this point in my lab is a very quiet set of targeted monitors that can detect the crumbs left behind when an attacker penetrates the environment. This test was only in my lab, so at this point, please feel free to let me know via the comments if you can replicate this or if your production environments are picking up noise that I’m not seeing in my lab. The goal is to leave a user with alerts that are actionable. I can provide the MP I’m developing (though of note I’m doing other things in here as well). If you’re interested in that, hit me up on linked in and I’ll be more than happy to share it.