1. First of all, there is heritance mechanism for “HTTP redirect”. If you configure this at IIS server level, all websites as well as subfolders and sub-applications will all inherit this http redirect rule. If you configure this at website level, all subfolders and sub-applications under this website will inherit this rule.
2. So if you add this rule at server level, this rule will take effect for all incoming requests, not only for one website, if you have multiple website on this IIS, in this way, all requests to this server will still be redirected to your destination configured in HTTP redirect. But you could change the settings for other websites manually by unchecking the inherited rule, then all sub-level setting will be canceled.
3. If you figure out there exists infinite redirecting loop, you’d better check all sublevel settings
4. If you want to redirect all requests to specific page, you’d better check “redirect all requests to exact destination”. for example, if you want to redirect all requests to https://hostname/test2/index.html

1. Log on Azure Classic Portal https://manage.windowsazure.com/
2. Open the Active Directory.
3. Click on Add button.
4. Select "Add an application my organization is developing" on the popup dialog.
5. Set the new application properties to:
   • Name: CRM OAuth2 Demo (you can use what name you want)
   • Type: Web application and/or web API

6. Click Next button.
7. Set the following application properties: (Any urls we can set here I think because we can change them later, just make sure the validations can be passed.)
   • Sign-On URL: https://localhost:1234
   • APP ID URL: https://alphac25.onmicrosoft.com/crmoauth2demo
   Click Complete button.

8. The new application titled CRM OAuth2 Demo will be added to the list of applications in the selected Azure Active Directory.
9. Select the new application titled CRM OAuth2 Demo.
10. The Application Configuration Tab is displayed with the Client Id.
11. Configure a client secret for the application. To generate an access token, we need to configure a client secret. To do this we add a key to the application in Azure AD. Below is a step by step guide to do this.
    • Following on from the previous section, scroll down to the keys on the applications configuration screen
    • Create a new key by selecting 2 years in the Select Duration drop down list.
    • Click Save.
12. Store the generated key (Client Secret) in a safe place because it will not be visible the next time the keys screen is displayed.
13. Assign Dynamics CRM permissions to the Demo application
    • Continuing from the previous section, on the applications configuration scroll down to the permissions to other applications section.
    • Click on the Add application button.
    • The permissions to other applications dialog is displayed.
    • Select Dynamics CRM Online.
    • Click the Add button.
    • Click the Complete button (tick in the lower right corner of the dialog).
    • Dynamics CRM Online is added to the permissions to other applications list.
    • Check the Access CRM Online as organization user permission from the Delegated Permissions drop down list.
    • Click save.

1. Add an action to acquire access token. Note*: Set Headers: Cache-Control: no-cache Content-Type: application/x-www-form-urlencoded Set Body: client_id: Client ID from Azure AD client_secret: Client ID from Azure AD username: username of the crm user password: crm user's password resource: crm url eg: https://alphac25.crm5.dynamics.com grant_type: password

2. Add an action to Parse the HTTP response.
3. Add another HTTP action to call CRM WebAPI: Note*: Authorization: Bearer <access_token> Accept: application/json OData-Version: 4.0 Cache-Control: no-cache

By default, Web deploy is using TLS1.0 to synchronize. I’ve met some customers who want to set TLS1.2 as default protocol.

Web Deploy needs to be running in windows 2008 R2/Windows 7 or above with .NET Framework 4.5.x or .Net Framework 4.6 installed, since TLS 1.2 /RFC 5246 was released to industry in Aug. 2008. Any earlier version of windows and .NET Framework cannot support TLS 1.2 runtime. To use TLS1.2, you’ll first need to update .NET framework to meet the requirement.

ALSO, below changes should be implemented only on the client (where msdeploy.exe is running) and not on the server (where IIS web server is running).

1. Create key about TLS1.2 if don’t exist.

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

           "DisabledByDefault"=dword:0

           "Enabled"=dword:00000001

•  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\ v4.0.30319

            "SchUseStrongCrypto" =DWORD32:1

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319\System.Net.ServicePointManager.SecurityProtocol

           "C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" =String:"tls12"

       The above name should be the location your msdeploy.exe installed in your machine.

https://support.microsoft.com/en-us/help/3154518/support-for-tls-system-default-versions-included-in-the-.net-framework-3.5.1-on-windows-7-sp1-and-server-2008-r2-sp1

https://www.iis.net/downloads/microsoft/web-deploy

https://www.microsoft.com/en-sg/download/details.aspx?id=48130

1. Install Windows SDK which includes Windows Debugger (by clicking Install SDK)

https://developer.microsoft.com/en-us/windows/downloads/sdk-archive

2. Only select Debugging Tools for Windows to finish install.

3. Open Powershell Command, run this command to get your application ID:

Get-appxpackage | select-string WPFUWP

For example, I go the result: WPFUWP_1.0.0.1_x86__s46g25shpckvj for my App WPFUWP.

4. Based on your app bit, open Command Window, use 32bit (x86) folder or 64bit (x64) folder of Windows Debugger, run this command (my wpfuwp is 32bit app, so I choose Debuggers\X86) to enable debugging tool for my App:

“C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\plmdebug.exe” /enableDebug WPFUWP_1.0.0.1_x86__s46g25shpckvj "C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\WinDbg.exe -c g"

5. Launch the App and recreate the crash issue. The Windbg will auto-break the crash point, and stop App running or existing.

6. Open Windbg, in the command line, run this command:

.dump /ma /u c:\output\crash.dmp

Then can start check the crash.dmp as postmortem analysis by debugging expert.

After getting dump, can run this command to auto attach debugger on my app:

plmdebug /disableDebug WPFUWP_1.0.0.1_x86__s46g25shpckvj

Thanks,

Freist]]> https://docs.microsoft.com/archive/blogs/asiatech/iis-8-5-binds-to-all-ip-addresses-on-a-server Wed, 15 Feb 2017 11:15:51 GMT https://blogs.msdn.microsoft.com/asiatech/?p=5175  

If you have multiple IPs in one windows server 2008 and above, when you add a website in IIS, you might found that 0.0.0.0 is listening on 80 or 443, rather than the IP address you just added. In this article, I will talk about the root cause and workarounds for this kind of scenario.

Backgrounds:

1) I have a windows server 2012R2 with two IP address A and B.

2) add a new website 1, bind it to IP A with 80 port, add another website 2, bind IP B and 80 port.

3) run “netstat -ano”, would find below result:

Active connections:

Proto local address state PID

TCP 0.0.0.0:80 LISTENING 4

The 80 port on all IP addresses are listening.

4) stop website 2, IP B:80 should be released and stop listening, If I try to telnet IP address B which is not occupied by any websites now:

telnet B 80

it would be successful.

5) The scenario is not expected, as I have already stopped website 2.

Root cause:

It is due to a feature designed in IIS, Socket Pooling. Socket pooling causes Internet Information Services (IIS) to listen to all IP addresses.

disable Socket pooling?

I did try to disable socket pooling following https://support.microsoft.com/en-us/help/238131/how-to-disable-socket-pooling, however failed.

Here is the reason: Because DisableSocketPooling is defined as a valid property in the IIS 6.0 metabase schema (MBSchema.xml), you can still set this property by using Adsutil.vbs, but this has no effect.

Workaround:

Fortunately, In this situation, if we want to delete the port 80 bound with 0.0.0.0, we can manually delete the HTTP listening rule.

1) When stopping website 2 in IIS console, if want IP B stop listening on port 80, please run below command:

netsh http delete iplisten ipadd=IPB:80

2) Now, we can find that we cannot telnet IPB:80 anymore.

3) In the same way, if you need to start the website again, not only to start it on the IIS manager, run below command to add HTTP listening as well.

netsh http add iplisten ipadd=IPB:80

More references:

https://support.microsoft.com/en-us/help/813368/setting-metabase-property-disablesocketpooling-has-no-effect

https://support.microsoft.com/en-us/help/238131/how-to-disable-socket-pooling

https://support.microsoft.com/en-hk/help/954874/iis-binds-to-all-ip-addresses-on-a-server-when-you-install-iis-7.0-on-windows-server-2008

https://msdn.microsoft.com/en-us/library/cc307219(VS.85).aspx

https://msdn.microsoft.com/en-us/library/cc307227(v=vs.85).aspx

Thanks,

Cynthia Jiang from DSI team]]> https://docs.microsoft.com/archive/blogs/asiatech/transfer-encoding-chunked-is-not-in-the-response-header-when-using-arr Wed, 15 Feb 2017 11:13:19 GMT https://blogs.msdn.microsoft.com/asiatech/?p=5165  

One of my customer is using ARR (Application Request Routing) in IIS8.5 as a reverse proxy to route the incoming requests to an application which does its own chunked transfer encoding. However, they find the “transfer-encoding: chunked” is not in the response header when using ARR, which causes the failure of the application connection.

Root Cause

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

In IIS 7 and above, it automatically buffers responses data going back to the client, up to 4MB by default. If any application sends a response less than 4MB, IIS will buffer it in its entirety and send the response with a Content-Length header. If buffering is enabled and the application sends a response without a Content-Length header - and the response exceeds the buffer size or is explicitly flushed by the app before its complete - the buffering code will automatically chunk transfer encode the response if appropriate. If the application manually does its own chunked transfer encoding, it may strip the chunked transfer encoding and send the buffered response with a content-length.

Solution

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

We can try to disable buffering by changing the Response Buffer Threshold (KB) to 0 in ARR Server Farm Proxy setting.

Here is a test of the solution by using ARR to route the request to a public chunkedimage page https://www.httpwatch.com/httpgallery/chunked/chunkedimage.aspx .

By default, when accessing this page through ARR, it will buffer the response and send the response with a Content-Length header.

When we change the Response Buffer Threshold (KB) to 0 in ARR Proxy setting. We can see the Transfer-Encoding: chunked in response header this time.

-Yingjie Shi from APAC DSI team]]> https://docs.microsoft.com/archive/blogs/asiatech/how-to-send-a-email-to-the-subscriptions-admin-in-logic-apps Wed, 15 Feb 2017 11:06:17 GMT https://blogs.msdn.microsoft.com/asiatech/?p=5115  

Logic Apps provide a way to simplify and implement scalable integrations and workflows in the cloud. Using Logic Apps and Azure Service Management REST API (https://msdn.microsoft.com/en-us/library/azure/ee460799.aspx), you can create an application to manage your service’s resources programmatically. In this article, we will demonstrate how to get the email address of Azure subscription and send an email in Logic Apps dynamically.

Pre works:

1. Create a management certificate

Please follow the steps in this document to create your management certificate:

https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-certs-create

2. Upload your management certificate through Azure classic portal

Then you need to upload your management certificate to your subscription (public certificate .cer file) so that it is authorized to perform management operations on your behalf. Please follow this documentation for step-by-step details:

https://docs.microsoft.com/en-us/azure/azure-api-management-certs

3. Find the API you needed.

In this sample, we will call an REST API to get the User Accounts information:

GET https://management.core.windows.net/<subscription-id>/principals

https://msdn.microsoft.com/en-us/library/azure/dn469420.aspx

Logic Apps:

Part A: Create a Logic App to get the email of Admin (Parent Logic App).

1. Create a request trigger.

We created a request trigger here to start our workflow. But you can use any other triggers.

More information you can find here: https://docs.microsoft.com/en-us/azure/logic-apps/logic-apps-http-endpoint

2. Create an HTTP action.

In this action, we will call Azure REST API using client certificate (pfx + password).

Note: You need to base64 encode the pfx file content and embed in the pfx textbox.

3. The format of the response body is a xml file as follows:

<?xml version="1.0" encoding="utf-8"?> <Principal xmlns=”https://schemas.microsoft.com/windowsazure”> <Role>role-names-for-user-account</Role> <Email>email-address-for-user-account</Email> </Principal>

In Logic Apps, it is more convenient to pass the data as a JSON file between different actions or apps.

You can use @JSON() function to convert the XML content easily in Logic Apps as below:

In real word, you can define any actions after you got the response message.

Here we defined a child logic apps to parse the response and send email -- sendEmail.

Part B: Create a Logic App to parse the response and send email to Admin (Child Logic Apps).

The sendEmail app takes an array of subscription admins and uses Send email action inside a ForEach loop

1. Create a request trigger to accept the response.

Here is a sample of the JSON format playload:

{ "Principals": { "Principal": [ { "Role": "ServiceAdministrator;AccountAdministrator", "Email": "user1@microsoft.com" }, { "Role": "CoAdministrator", "Email": "user2@microsoft.com" } ] } }

Put the above JSON data to https://jsonschema.net to get the its JSON schema.

Paste the schema definition in request trigger. With the help of JSON schema, Logic App could automatically tokenize all properties e.g. Principals, EmailId etc.

2. Create a ForEach action – Loop over all principals

a. Send Email action – Send email using Office 365 send email action.

3. Response action – Child workflows should have response action to be callable from another logic app use native child workflow action.

Special thanks to Vinay Singh, Xiaodong Zhu.

Ray Wang from DSI team.]]> https://docs.microsoft.com/archive/blogs/asiatech/how-iis-interferes-in-group-policy-log-on-as-a-service Sat, 04 Feb 2017 05:17:09 GMT https://blogs.msdn.microsoft.com/asiatech/?p=5025  

Since windows server 2008, there exists a Group policy called Log on as a service, it’s located in Group policy\Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment.

As introduced in the Microsoft official document https://technet.microsoft.com/en-us/library/dn221981(v=ws.11).aspx , it’s used to determine which service accounts can register a process as a service.

By checking into this group policy, we will see the the application pool identity inside as below:

Apparently, it’s necessary to add the corresponding identities into this group policy for launching the specific application pool.

Additionally, they are automatically inserted by IIS, no need to manually operate it.

When IIS will add the identities into Log on as a service?

1. All the existing application pool identities will be added when IIS was initialized

2. When an application pool’s w3wp process is launched, IIS will check if its identity already exists in Log on as a service. If not, it will be added.

Attentions:

1. For an application pool which is running under OnDemand mode, if its identity is not included in Log on as a service, IIS will not add it until the corresponding w3wp process is launched upon the first request. The identity check and insert operation happens when the w3wp process is launched instead of the application pool is started in IIS Manager.

2. When adding the identities, IIS will not recursively check the identities in Log on as a service. That is to say, a new identity will still be added even if one of its groups might have been existing inside. In a word, the application pool identities cannot be added in the form of group.

Special thanks to Xiaodong Zhu.

Jinjie ZHOU from DSI team.]]> https://docs.microsoft.com/archive/blogs/asiatech/how-to-keep-escape-characters-of-slash-in-url-when-using-iis-arr Wed, 11 Jan 2017 23:07:05 GMT https://blogs.msdn.microsoft.com/asiatech/?p=4975  

Recently I encountered an issue that customer would like to keep Escape Characters (in this case, it’s slash ‘/’, which is encoded to ‘%2F’) in URL, when using IIS ARR to forward the request to backend server. For example, if the Browser send a request containing /a%2Fb to IIS, then ARR would forward the request to backend server, you may found backend server would receive the request being replaced to /a/b.

Actually, the reason is URL Rewrite performs matching and rewrite based on the cooked URL (canonical form, decoded) provided by the underlying HTTP layer (HTTP.sys). When process decoded URL, URL Rewrite has no knowledge on whether the original form of ‘/’ is “%2F” or it’s just a regular delimiter. As a consequence, when URL Rewrite encode the final forward URL for ARR, it just leaves ‘/’ as it is. This is a default behavior.

Workaround

==========

It would be best to avoid this kind of URL. But if your website must send request containing ‘%2F’, here is a workaround: USING DOUBLE ESCAPE.

In detail, set system.webServer/security/requestFiltering/allowDoubleEscaping to true, and modify the original URL to /a%252Fb (encode ‘%’ to ‘%25’). After that, the backend server could receive the request as /a%2Fb.

More references:

https://blogs.iis.net/nazim/use-of-special-characters-like-in-an-iis-url

https://blogs.iis.net/wadeh/how-iis-blocks-characters-in-urls?CommentPosted=true#commentmessage

Thanks,

Cynthia Jiang from DSI team