Ir al contenido

Posts from the ‘Soluciones’ Category


Changing the maximum upload size for IIS 7.5

I hit a snag when uploading large files using PHP on IIS 7.5. I was getting some weird Error 404, which in most cases means the PHP script that handles the upload process was not found. I checked my server, and sure enough, the PHP script was there. I tried again to be sure, this time with a smaller file. And what do you know, it worked just fine.

This led me to believe that there was a file size restriction imposed somewhere. I’ve already modified the php.ini file to allow me to upload larger files, but still no go. So the only other thing I can think of was IIS. Apache has something like that, so it’s only obvious that the ever-so-cautious IIS would be the same.

After much research, and a couple of Google searches later, I found a simple solution involving some simple config file edits. Damn, after working with IIS for the past 6 months, I got used to not having to deal with config files. Anyway, the file you want to modify is “C:\Windows\System32\inetsrv\config\applicationHost.config”. I don’t know if it makes any difference, but I’ve converted the folders that hold my PHP scripts into Applications through the IIS Manager.

So open that file up using any text editor. It was a newly installed virtual server, so I didn’t have anything other than Notepad available.

Add the following lines to the bottom of the file, making sure it’s inside the area.

Where “Default Web Site” is the name of your website, “alnet” is the name of the application, and “2147483648″ is the amount you want to set for the upload file limit in bytes. So as you can see, I’ve set my IIS to accept file sizes up to 2GB. You can add as many of this as you need. I have 3 applications, so I have three of these in my config XML script. You can also use the following line at a command prompt. Be sure to navigate to “C:\Windows\System32\inetsrv” first.

appcmd set config "Default Web Site/alnet" -section:requestFiltering

Where “Default Web Site” is your website and “alnet” is the name of your application.

That’s it. Have fun and if you know of a better way to achieve the same result, let me know using the comment form.

Until next time, Wassalam.


An easier way to go about this, as I’ve recently discovered, is to use the IIS Manager. I know, I know. This is by far the best way to go about this, but I don’t really have that much experience with Windows Server and I’m so used to the Linux way of editing configuration files that I didn’t think to use the IIS Manager for this. Anyway, here’s how to change the file upload limit using the IIS Manager.

Open up the Server Manager and navigate to the IIS Manager. Click on your Application icon and turn your attention to the center window. Scroll down to the bottom and you will find the Configuration Editor under Management. Double-click on this and you will be presented with a bunch of settings.

Open up the drop down menu and navigate through the following; system.webServer > security > requestFiltering. Click on that and it will show you the current requestFiltering settings for your Application. Scroll down and until you find requestLimits. Expand it and there you should see maxAllowedContentLength. You can now change this value to any value you wish to set. Once you’re done, click Apply and that’s it.

Here’s a picture showing you where and what to change. At this moment, I only have the Japanese version of Windows Server available to take screenshots from, but I’m sure you get the idea.

Obtained from this link


Cómo hacer capturas de pantalla en OS X

Una de las preguntas más frecuentes de quien se acaba de pasar a Mac, es cómo hacer capturas de pantalla en OSX. En PC hay una tecla llamada ‘Imprimir pantalla’, con la que podemos pasar lo que vemos en la pantalla al portapapeles para después pegarlo en Paint por ejemplo. Pero en Mac esa tecla no existe, ¿cómo hacemos una captura?

Es aún más sencillo, hay cuatro maneras:

Shift + Comando + 3

Con esta combinación de teclas, obtendremos automáticamente una captura de toda nuestra pantalla, y el archivo se creará en el escritorio con el nombre ‘Imagen 1.png’

Shift + Comando + 4

De esta otra manera, el cursor cambia a un punto de mira que podemos arrastrar para seleccionar a mano qué parte de la pantalla queremos capturar. También se crea un archivo en el escritorio con el nombre ‘Imagen 1.png’

Shift + Comando + 4, y después barra espaciadora

Si después de hacer la combinación de teclas anterior pulsamos la barra espaciadora, el cursor cambiará a una cámara fotográfica, de manera que podremos elegir qué ventana en concreto queremos capturar. La imágen capturada aparecerá en nuestro escritorio con el nombre ‘Imagen 1.png’.

Con el programa ‘Instantánea’


Dentro de nuestra carpeta ‘Aplicaciones’, en la carpeta ‘Utilidades’, podemos encontrar el programa ‘Instantánea’. Con él podremos hacer lo mismo que con los atajos de teclado anteriores, pero al capturar, la imágen se abre en una ventana y podemos imprimirla o guardarla donde queramos. Además hay un modo más: ‘Capturar pantalla con temporizador’. Funciona igual que las cámaras de fotos, hay una cuenta atrás de unos segundos y saca la foto.

Por último, cuando capturamos con las tres combinaciones de teclas, si pulsamos también la tecla ‘Control’, en vez de generar un archivo en el escritorio, la foto quedará guardada en el portapapeles para que la peguemos donde queramos.

Obtenido de este enlace


Installing SQL Server 2008 Reporting Services on Failover Cluster in already clustered instance

A way of achieving SQL Server 2008 High Availability is installing SQL Server on top of Windows Server 2008 failover cluster. Only Database Engine Services and Analysis Services are cluster aware while SQL Server 2008 Reporting Services and shared components (Integration Services, Management Studio, Business Intelligence Development Studio etc.) are not.

According to available documentation installing Reporting Services in already clustered SQL Server instance is not supported. If you want the Reporting Services on the other nodes you must install them in separate SQL Server instances. If you want the highly available Reporting Services they should be deployed in a farm which provides both availability and load balancing.  For details see Planning and Architecture (Reporting Services) .
What I needed was High Availability, but I didn’t have additional servers to create the farm (with this scenario you need at least 2 additional servers for farm or NLB). Also I didn’t want to manage multiple SQL Server instances side by side. Multiple instances mean a lot of administration because each instance must be handled separately. There are scenarios when you should or want to use multiple instances, but not in my case. Use of existing Windows/SQL failover cluster seemed logical. Described solution is tested and deployed using both SQL Server 2008 and R2 Enterprise Edition. Standard Edition of SQL Server does not support Scale-Out deployment. For details see Planning for Scale-Out Deployment.
Setup of SQL Server 2008 failover clustering has changed in this release. To install or upgrade a SQL Server failover cluster, you must run the Setup on each node of the failover cluster. You create a failover cluster by running Setup on first node and selecting all desired components.  As I already mentioned only the Database Engine and Analysis Services support failover clustering, while other components run as a stand-alone feature without failover capability. Shared components are installed on all other nodes while adding those nodes to the existing failover cluster. To install the Reporting Services on other nodes, after adding those nodes to the existing SQL Server failover cluster, you must run setup once again.
Running setup on the second node and selecting the Reporting Services caused setup to fail with following error:
” StandaloneInstall_HasClusteredOrPreparedInstanceCheck
Checks if the selected instance name is already used by an existing
cluster-prepared or clustered instance on any cluster node.Failed – The instance selected for installation is already installed and
clustered on computer . To continue, select a different instance to
The Solution is to run setup and skip this check to install the Reporting Services in already clustered instance.
Run the following command at the command prompt to start setup and add Reporting Services on other nodes:
Setup.exe /SkipRules=StandaloneInstall_HasClusteredOrPreparedInstanceCheck /Action=Install
This will run Setup in full interaction GUI mode while skipping cluster instance check. Just follow setup to install Reporting Services in SQL Server clustered instance.
General steps for installing SQL Server failover cluster with Reporting Services on each node are:
1.    Create SQL Server failover cluster by installing first node. Start setup and select option “New SQL Server failover cluster installation”. Make sure you select Reporting Services while installing first node.
2.    Install SQL Server failover clustering on other nodes. Start setup and select option “Add node to a SQL Server failover cluster”. You can not chose any features. You will add Reporting Services later.
3.    Install Reporting Services on all nodes except first node in SQL Server clustered instance. Run setup from command prompt using command mentioned above.
4.    Configure Reporting Services on each node. Run “Reporting Services Configuration tool” on each node.
After installing Reporting Services on failover cluster please keep in mind:
  • Reporting Services running on an Active-Passive cluster handle requests on each cluster node on which the service is deployed.
  • Report server must be configured to use SQL failover cluster virtual name to connect to the report server database. This is because it is hosted on a SQL Server that is part of a failover cluster. If not, the report server will be unable to connect to the report server database if a failover occurs.

This solution provides the highly available Reporting Services with default SQL server instance and uses already deployed hardware. It is not substitute for a true Scale-out deployment of the Reporting Services, but a way of achieving high availability (we just used the existing high availability platform). Scale-out enables you to increase the number of users who can concurrently access/invoke reports and improves the availability of the report server.

Obtained from this link

Other link


Jumbo Frames/MTU en Hyper-V Server (Windows Server 2008/8 Core)

Enabling Jumbo Frame support in Hyper-V Server 2008 R2 (or Windows Server Core) has proven to be a bit of an adventure.  It really just involves setting the MTU size, but it has to be done in the OS (to affect the TCP/IP stack) as well as the network cards’ driver.  Since Core versions of Windows do not have a network control, setting the MTU on the cards proves to be a bit of a trick.  This is what I had to do to enable Jumbo Frames on several iSCSI nics, and since it differs for Intel vs Broadcom adapters, there are two procedures.

I should point out that this does not address configuring the network switch that these nics are attached to.  That is a whole ‘nother can of worms, but suffice it to say that the switch must not only support Jumbo Frames but have that support enabled, along with a whole host of other settings.

Enable Jumbo Frames on the OS

The first thing you need to do is make sure that your server will allow jumbo frames.  You do this by setting the MTU on your adapters to 9000.  The easiest way to do this is by running a netsh command on each adapter you want to use Jumbo Frames.

Get a list of interface names by running “netsh int show int

Admin State    State          Type             Interface Name
Enabled        Disconnected   Dedicated        Local Area Connection 2
Enabled        Connected      Dedicated        Bcom-GB3-iSCSI-A
Enabled        Connected      Dedicated        Local Area Connection
Enabled        Connected      Dedicated        Local Area Connection 3
Enabled        Connected      Dedicated        Local Area Connection 4
Enabled        Connected      Dedicated        Bcom-GB4-iSCSI-B
Enabled        Connected      Dedicated        Intel-GB1-Guest-B
Enabled        Connected      Dedicated        Bcom-GB2-Guest-A
Enabled        Connected      Dedicated        Intel-GB2-Guest-C
Enabled        Connected      Dedicated        Bcom-GB1-Mgmnt
Enabled        Connected      Dedicated        Intel-GB3-iSCSI-C
Enabled        Connected      Dedicated        Intel-GB4-Migration

In this case I have already re-named the Interfaces that I intend to use for iSCSI.  You might just see a whole list of “Local Area Connection” interfaces.  You can use ipconfig or netsh to further identify which ones you want to use.

Now for each interface you want jumbo frames enabled, run this command:

netsh int ipv4 set subint “” mtu=9000 store=persistent

Now you have to configure Jumbo Frames in the driver for each interface.

Enable Jumbo Frames on Intel cards

The Intel driver stores it’s “Jumbo Frame” settings in the registry.  Thankfully, Hyper-V Server (and Windows Core) comes with Regedit, so you can just launch that from command line (regedit.exe) and browse to the following key:


Here you will see all the network interfaces listed by GUID.  I have found that the easiest way to determine which GUID is which adapter is by finding the IP address and being able to correlate it to the right Interface name.

At this point you should start making a list to help keep things straight.  Copy the GUID into notepad and list the IP address next to it and do this for each card you want to configure.  So for this server, my list looks like this:

SERVERNAME {7A310D71-217C-4E4A-9DA7-43299A76CBD5}
SERVERNAME {7BC7F3B9-B245-4579-82CB-C94161BFDBC1}
SERVERNAME {8BA5076E-0FC3-4D20-9609-654F228EE6BD}
SERVERNAME {98ABBECA-B8A2-41D2-9550-8B571E50F49A}

Now we have to navigate to a new registry key to configure the driver.  Go here:


Here you will again see a list of all network interfaces, only this time they are under 4 digit identifiers.  From here, search for the GUID that you copied to your list and you should find it as the “NetCfgInstanceId” key of one of the adapters.  Once found, it’s not a bad idea to update your list to keep track of what’s what.  Mine looks like this now:

SERVERNAME {7A310D71-217C-4E4A-9DA7-43299A76CBD5}  0009 Intel
SERVERNAME {7BC7F3B9-B245-4579-82CB-C94161BFDBC1}  0005 Broadcom
SERVERNAME {8BA5076E-0FC3-4D20-9609-654F228EE6BD}  0004 Broadcom
SERVERNAME {98ABBECA-B8A2-41D2-9550-8B571E50F49A}  0008 Intel

Scroll up to find the “*JumboPacket” key and double click it to change the default value of 1514 to 9014.  Note the extra 14 bytes here represents packet headers that normally are not counted in MTU size.

Repeat this for each Intel adapter you need to configure, and then reboot the server for the setting to take effect.

Enable Jumbo Frames on Broadcom cards

First make sure you have the latest Broadcom drivers.  Make sure you get the 2008 R2 x64 set.

If you haven’t already, then download and install the driver and then reboot the host.  Note: Make sure you migrate any existing guest servers off the host before you install the drivers.  The temporary outage of the card due to the update seems to make a failover cluster angry.

Now get the Broadcom Management Application suite.  Again, get the x64 set from the same page.

Install the management app.  I opt’d not to install the BASP component (see screenshot below) since we do not want failover or teaming in this scenario.  It’ll likely warn you that you need the dotNet Framework 2.0 and you should be able to ignore this because the installer just does not recognize the “Core” framework, but the application still runs.  To make sure you do in fact have the framework installed, run “oclist | findstr /i netfx” and look for a line stating that NetFx is installed.  For example, “Installed:NetFx2-ServerCore”.  If not, you can install it by running “start /w ocsetup NetFx2-ServerCore” or instead you can install dotNet 3.0 and 3.5 by running “start /w ocsetup NetFx3-ServerCore”.

From C:Program FilesBroadcomBACS run “BACSCLi” to run in interactive mode.  It will show you a list of all network adapter drivers installed.  You only care about the “NDIS” adapters so enter “list ndis” and you’ll see something like this:

C  MAC          Dev Type Name
-  ------------ -------- ----------------------------------------------------
0  001B214285B8 NDIS     [0000] Intel(R) Gigabit ET Quad Port Server Adapter
1  001B214285B9 NDIS     [0007] Intel(R) Gigabit ET Quad Port Server Adapter #2
2  001B214285BC NDIS     [0008] Intel(R) Gigabit ET Quad Port Server Adapter #3
3  001B214285BD NDIS     [0009] Intel(R) Gigabit ET Quad Port Server Adapter #4
4  0026B9429866 NDIS     [0002] Broadcom BCM5709C NetXtreme II GigE (NDIS VBDClient)
5  0026B9429868 NDIS     [0003] Broadcom BCM5709C NetXtreme II GigE (NDIS VBDClient) #2
6  0026B942986A NDIS     [0004] Broadcom BCM5709C NetXtreme II GigE (NDIS VBDClient) #3
7  0026B942986C NDIS     [0005] Broadcom BCM5709C NetXtreme II GigE (NDIS VBDClient) #4

If you did the Intel configuration you’ll notice the four digit number in square braces of the Name field matches the ControlClass registry key.

Use some combination of “ipconfig /all” in another window or CtxAdmTools’ Visual Core Configurator 2008 or the four digit registry code to identify the adapter that you want to configure.  In this example we want Connection #6.  Select it by using “select 6” or whatever number is in the “C” column that matches your adapter.  Now validate that you have selected the correct adapter by reviewing some of its details.  Run “info” to see it’s MAC/IP, etc.

Vital Signs
MAC Address:              : 00-26-B9-42-98-6A
Permanent MAC Address:    : 00-26-B9-42-98-6A
IPV4 Address              :
Link Status               : UP
Duplex:                   : Full
Speed(in Mbps):           : 1000
Offload Capabilities      : TOE,LSO,CO,RSS
Mtu                       : 1500
Driver Information
Driver Status:            : Loaded
Driver Name:              : bxnd60a.sys
Driver Version:           :
Driver Date:              : 07/30/2009

Notice the MTU setting is set to 1500 by default.  Now run “cfg advanced” to list its advanced properties.

Ethernet@WireSpeed:                     Enable (Default)
Flow Control:                           Disable
IPv4 Checksum Offload:                  Tx/Rx enabled (Default)
IPv4 Large Send Offload:                Enable (Default)
IPv6 Checksum Offload:                  Tx/Rx enabled (Default)
IPv6 Large Send Offload:                Enable (Default)
Interrupt Moderation:                   Enable (Default)
Jumbo MTU:                              1500 (Default)
Locally Administered Address:           Not Present (Default)
Number Of RSS Queues:                   8 (Default)
Priority & VLAN:                        Priority & VLAN enabled (Default)
Receive Buffers:                        750 (Default)
Receive Side Scaling:                   Enable (Default)
Speed & Duplex:                         Auto (Default)
TCP Connection Offload (IPv4):          Enable (Default)
TCP Connection Offload (IPv6):          Enable (Default)
Transmit Buffers:                       1500 (Default)
VLAN ID:                                0 (Default)
Wake Up Capabilities:                   Both (Default)

Run “cfg advanced “Jumbo MTU”=9000” to set Jumbo frames to 9000 bytes.  Note that you do not have to account for the 14 bytes of header data here.  It’ll take a few seconds to apply the change but you should not need to reboot (yay!).  You can now run “cfg advanced” and “info” to list the settings and ensure that the MTU is in fact set to 9000.

You should also enable Flow Control for Transmit (Tx) and Receive (Rx).  With the correct adapter already selected, run “cfg advanced “Flow Control”=”Rx & Tx enabled””.

Once that is complete you can enter “q” to exit BACScli or start over using “list ndis” and select another interface to configure.  You can also use this utility to select non-Broadcom adapters to display some of their info like MTU size.

Testing Jumbo Frames

To test if Jumbo Frames are working you can ping another host target that also supports Jumbo Frames.  The easiest way that I have found to do this was to just change the IP of your test NIC and your test target NIC to something that no other adapter has.  This is because there is no way to tell windows specifically what NIC to send traffic over, so setting the NIC’s to their own network ip space is the only way to ensure that the ping traverses a particular adapter.

For example, I changed the source test nic to and the target to and no other adapters on either host saw set in the 172.16.1.* range.

First try a normal “ping” and it should work fine.  Then use “ping -f -l 6000” to test jumbo frames and it should also work, only this time you’ll see it sending 6000 bytes instead of 32.

So that about covers it.  I had to do this for each of the 32 iSCSI nics spread across the 8 host servers, but it works!  You should be aware that if you do a driver update or if you share a NIC with a virtual network (as a Hyper-V Host) your settings may be lost and you’ll have to go through this again.

Obtained from this link


Winhttp Tracing Options for Troubleshooting with Application Request Routing

Since  there are multiple ways to gather this in the Windows 2008 and 2008R2 I thought this might be helpful to outline this for the different platforms and how to gather this for fellow ARR troubleshooters.

Windows 2008

1. Start the Tracing . From a command prompt run the following command:

netsh winhttp set tracing trace-file-prefix=”C:TEMPWinHttpLog” level=verbose format=hex state=enabled max-trace-file-size=1048576000

2.Recycle the IIS Application Pool.

3. Reproduce the issue.

4. Stop the Tracing. From a command prompt run the following command:

netsh winhttp set tracing state=disabled

5. Review the trace with Notepad or any Text editor.

NOTE: The Identity of the  IIS application pool will require write access to the  log location  c:Temp in this example:

This type of tracing is process bitness specific, so if you are looking at a 32 bit process running from 64 bit OS, you need to use: c:windowssyswow64cmd.exe, rather than using the regular 64 bit cmd.exe (start a run a cmd.exe)

Windows 2008 R2

Method 1

This method will output the Winhttp API calls , but not raw data for network communication. From a command prompt run the following command:

1. Start the tracing

netsh winhttp set tracing trace-file-prefix=”C:TempTest3″ level=verbose format=hex

netsh winhttp set tracing output=file max-trace-file-size=512000 state=enabled

2.Recycle the IIS Application Pool.

3. Reproduce the issue.

4. Stop the Tracing. From a command prompt run the following command:

netsh winhttp set tracing state=disabled

5. Review the trace with Notepad or any Text editor.

NOTE: The Identity of the IIS application pool will require write access to the log location c:Temp in this example:

This type of tracing is process bitness specific, so if you are looking at a 32 bit process running from 64 bit OS, you need to use: c:windowssyswow64cmd.exe, rather than using the regular 64 bit cmd.exe (start a run a cmd.exe)

Method 2

To get the raw data communication at network layer and the Winhttp  Api calls.

1. Start the tracing: From a command prompt run the following command:

netsh trace start scenario=InternetClient capture=yes report=yes

Note the etl file location for example:

Trace File:         C:UsersAppDataLocalTempNetTracesNetTrace.etl

2.Recycle the IIS Application Pool.

3. Reproduce the issue.

4. Stop the tracing: From a command prompt run the following command:

netsh trace stop

5. Read the Trace by opening it in Netmon 3.4.

Method 3

The ETW format for winhttp API is available on windows 2008 R2 and win7 via the Event Viewer

1.  Open event viewer. Go to “View” menu –> make sure “Show Analytic and debug logs” is checked.

2. Open “Applications and Services logs” — > Open “Microsoft” — > Open “Windows –> Winhttp –> Diagnostic.

3. Highlight “Diagnostic” under Winhttp tree and right click mouse, then click “enable log”.

4.  Reproduce the issue then you can review the logs.


Netsh Commands for Network Trace in Windows Server 2008 R2 and Windows 7

Obtained from this link


502.3 Bad Gateway “The operation timed out” with IIS Application Request Routing (ARR)

When working with ARR deployments one of the errors you might see is  502.3  Bad Gateway. The 502.3 means while acting as a proxy ARR was unable to complete the request to the upstream server and subsequently send a response back to the client. This can happen for multiple reasons including , failure to connect to the server , no response from the server, or server took too long to respond (time out).

For the purposes of this post we are going to look at a timeout error and the data that can be gathered to help isolate the cause.

If you are looking at this post then you probably have already seen this error or something similar. This is shown in the browser when detailed errors are enabled in IIS.

Another way to identify the source of the 502.3  is with Failed Request Tracing   logs in IIS configured to capture Status code 502.

From the message the key details are the ErrorCode  which you can use to map to to the Winhttp error message, which in this case is ERROR_WINHTTP_TIMEOUT ( Reference WinHttp Error Codes). You will also see in the next line that this is translated to “The operation timed out”.  Note that both the 0x80072ee2 and 2147954402 map to the same error  ERROR_WINHTTP_TIMEOUT.

Now that we know its a timeout we need to determine what type of timeout occurred. Here is a list of the timeouts that can occur in Winhttp ( which if you haven’t guessed already is what ARR uses to proxy requests)

  • ResolveTimeout : This occurs if name resolution takes longer than the specified timeout period.
  • ConnectTimeout : This occurs if it takes longer than the specified timeout period to connect to the server after the name resolved.
  • SendTimeout  :     If sending a request takes longer than this time-out value, the send is canceled.
  • ReceiveTimeout :  If a response takes longer than this time-out value, the request is canceled.

To identify what type of timeout we can use Winhttp’s built in logging,These can be enabled from the command line on the ARR server using NETSH.

  • Winhttp Traces:

Following  the example below you can search your log for WinHttpOpenRequest to find your request. The calls to WinHttpSetTimeouts  are setting the 4 timeout values  based on your ARR time settings found in the Proxy Configuration page of your ARR Server Farm or in the Server Proxy settings. Next we find WinHttpSendRequest then WinHttpReceiveResponse , so we know we are now in the receive stage. Finally we see that the error in is in RecvResponse so we know this is a ReceiveTimeout. For a different failure such as ResolveTimeout  we would not see the log make it to WinHttpReceiveResponse and the failure would be logged earlier.

10:23:45.100 ::WinHttpOpenRequest(0x35a970, "GET", "/sleep/default.aspx", "HTTP/1.0", "", 0x0, 0x00000080)
10:23:45.100 ::WinHttpSetTimeouts(0x2e42d80, 30000, 30000, 30000, 30000)
10:23:45.100 ::WinHttpSetTimeouts() returning TRUE
10:23:45.100 ::WinHttpSendRequest(0x2e42d80, "Accept: */*rnAccept-Encoding: gzip, deflaternAccept-Language: en-CArnHost:", 479, 0x0, 0, 0, 24794c0)
10:24:15.397 ::Completing WinHttpSendRequest() with success; Request Handle = 02E42D80, Context = 024794C0, Buffer = 00000000 (0x0), Buffer Length = 0
10:24:15.397 ::WinHttpReceiveResponse(0x2e42d80, 0x0)
10:24:15.397 ::sys-recver failed to receive headers; error = ? (1460)
10:24:15.397 ::ERROR_WINHTTP_FROM_WIN32 mapped (?) 1460 to (ERROR_WINHTTP_TIMEOUT) 12002
10:24:15.397 ::sys-recver returning ERROR_WINHTTP_TIMEOUT (12002) from RecvResponse()
10:24:15.397 ::sys-req completes recv-headers inline (sync); error = ERROR_WINHTTP_TIMEOUT (12002)

Now that we know this is receive timeout we can look at the content server and see how long the request took.

  • IIS logs on the  Content Server:

Examine the IIS logs on the  content server and check the sc-status and sc-win32-status and time-taken fields.  This will give you an idea of whether the request processed successfully ( sc-status = 200)  and the time-taken to see if this exceeds your ARR timeout and if this is the expected execution time for your web page . You can determine from this whether you need to troubleshoot a long running application or simply increase the ARR timeout settings. Checking the Win32 field for errors such as 1236 (ERROR_CONNECTION_ABORTED) or  64 (ERROR_NETNAME_DELETED) indicate that something happened on the network layer such as  a connection reset.

Using our example the IIS logs here show that the Request  took ~35 seconds (time-taken=35615) , the request was processed successfully on the server (sc-status=200) , but  there was a problem sending the request (sc-win32-status=64) which means the connection was gone when the content server tried to send the request.  This was because the client (ARR) has already timed-out and closed the TCP connection.

#Software: Microsoft Internet Information Services 7.0
#Version: 1.0
#Date: 2010-06-23 20:11:33
date time            cs-method cs-uri-stem         s-port  sc-status sc-substatus sc-win32-status time-taken
2010-06-23 20:11:33  GET       /sleep/default.aspx 80      200       0            64               35615


So in this case we can see that the request took >35 seconds  which is longer than the default timeout in ARR. When this occurs ARR  ( or Winhttp underlying ARR)  will close the connection to the content server which is what cause the Win32 error 64.

Now its up to you to determine whether its acceptable that your page is running for 35 seconds  and you just need to increase time outs in ARR.

Since the application issues are beyond the scope of this blog I’ll leave you with two command lines for setting ARR  timeouts for either a  Server Proxy  configuration or Server Farms.

Server Proxy : appcmd.exe set config  -section:system.webServer/proxy /timeout:”00:00:45″  /commit:apphost

Server Farm :  appcmd.exe set config  -section:webFarms /[name=’ArrFarm’].applicationRequestRouting.protocol.timeout:”00:00:45″  /commit:apphost



WinHttpSetTimeouts Function

Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP)

Failed Request Tracing in IIS (FREB)

UPDATE : New Post for Winhttp Tracing Methods


Obtained from this link


Combinaciones de teclas de arranque para ordenadores Mac con procesadores Intel

Puedes utilizar las siguientes combinaciones de teclas de arranque con los ordenadores Mac con procesadores Intel.

Pulsar C durante el arranque Arranca desde un CD, DVD o memoria USB de arranque (como por ejemplo el soporte de instalación de OS X).
Pulsar D durante el arranque Arranca en Apple Hardware Test (AHT).
Presionar Opción-Comando-P-R hasta que se escuche el sonido de inicio por segunda vez. Se restaura NVRAM
Pulsar Opción durante el arranque Arranca en el Gestor de arranque, donde se puede seleccionar un volumen de OS X desde el que arrancar. Nota: pulsa N para que aparezca también el primer volumen de Red de arranque.
Pulsar Expulsar, F12 o mantener pulsado el botón del ratón o del trackpad Se expulsan los soportes extraíbles, como por ejemplo, un disco óptico.
Pulsar N durante el arranque Intenta arrancar desde un servidor de red compatible (NetBoot).
Pulsar T durante el arranque Arranca en modo de disco de destino.
Pulsar Mayús durante el arranque Arranca en modo modo de inicio seguro y se desactivan temporalmente los elementos de inicio de sesión.
Pulsar Comando-V durante el arranque Arranca en modo modo verboso.
Pulsar Comando-S durante el arranque Arranca en modo modo de un solo usuario.
Pulsar Opción-N durante el arranque Arranca desde un servidor NetBoot utilizando la imagen de arranque predeterminada.
Pulsar Comando-R durante el arranque Arranca desde Recuperación de Lion1

1 Disponible en los Mac vendidos con OS X Lion. Algunas CPU requieren una actualización del ROM de inicio EFI para poder usar esta prestación.

Información adicional

Para obtener los mejores resultados con las teclas de arranque, púlsalas justo después de escuchar el tono de arranque.


ESET lanza ESET Mail Security para Lotus Domino y ESET File Security para Windows Server Core

ESET España, líder en protección proactiva contra todo tipo de amenazas, operado en España por, ha anunciado sus nuevos productos para servidor ESET Mail Security para IBM Lotus Domino y ESET File Security para Microsoft Windows Server Core. Las empresas interesadas en su prueba o más información, pueden solicitarla en la web de ESET España.

ESET Mail Security es una potente solución que ofrece protección sin sobrecargar los sistemas en servidores de correo electrónico con alta carga basados en IBM Lotus Domino. Comparado con la versión anterior, representa una importante actualización de ThreatSense, la tecnología de detección más precisa de la industria. Gracias a la completa protección contra cualquier tipo de amenaza procedente del correo electrónico, ESET Mail Security para IBM Lotus Domino ofrece una alta precisión a la hora de gestionar la seguridad del tráfico en servidores corporativos de correo.

“Alto rendimiento, escasa necesidad de recursos y una alta velocidad de exploración reflejan el compromiso de ESET para desarrollar soluciones de seguridad flexibles y eficientes para servidores críticos”, afirma Josep Albors, director del laboratorio de ESET España.

ESET Mail Security para IBM Lotus Domino es compatible con ESET Remote Administrator y soporta Lotus Domino Partitions. La solución, conocida por su forma de operar, excluye automáticamente archivos críticos del servidor a la hora de realizar los chequeos.

Desarrollos clave de ESET Mail Security para IBM Lotus Domino
Antivirus y antispyware: elimina cualquier tipo de amenaza, incluyendo virus, rootkits, gusanos y spyare. Protege a las pasarelas de email en los niveles SMTP y NRPC y escanea de forma regular todos los datos almacenados en Domino Server. La solución integra todas las herramientas para una protección global del servidor, incluyendo un escudo residente y un motor de exploración bajo demanda.
Antispam: retiene mensajes de phishing y spam de forma efectiva. La configuración del motor antispam se puede realizar desde una interfaz muy intuitiva.
Estadísticas y logs: mantiene al usuario al corriente de la situación del sistema con logs y estadísticas completas y detalladas que incluyen logs de spam y listas grises.

ESET ha anunciado también la nueva versión de ESET File Security para Microsoft Windows Server Core. La solución ofrece antivirus, antispyware, protección multiplataforma y gestión centralizada compatible con ESET Remote Administrator, ESET SysInspector y ESET SysRescue.

ESET respeta la filosofía de Windows Core, ya que no añade servicios no fundamentales para el funcionamiento del servidor y ofrece una protección avanzada sin necesidad de servicios o procesos que carguen el sistema.

Todas las empresas interesadas en más información o en la prueba del producto, pueden solicitarla a través de la web de ESET España.

Departamento de Marketing
ESET España


VMM 2008 R2 SP1: Error 3140 when trying to offline P2V WS2008R2

I just want to share some info from our recent P2V migration.

We have received 3140 error during offline P2V of Windows Server 2008 R2 (or Windows 7) using Virtual Machine Manager 2008 R2 SP1.

The progress bar stuck at 40% (step 1.3.1) with error 3140 without any description in VMM. When googling I’ve found the following link: . Per instructions I sent an email to Mike Briggs. However, Mike is no longer with the VMM Team but he go through the debug logs for me and find out that the final failure is “3140/80990C44” which translates to NETLOG_MSG_SHUTDOWN.

Finally i give up and ask Microsoft PSS for support, surprisingly the bug is quite simple: The boot image that VMM is using for offline conversion cannot fit into the 100MB default (classic install) system partiton [just a side note: the system partition is used for booting the system = boot sector, bootmgr, while the Boot partition contains Windows files]. In order to fix the issue:

  1. Open an elevated command prompt and run : bcdboot c:windows /s c:
  2. This will copy the required boot files to the C drive. Notice the hidden boot folder on the root of the C drive and also the bootmgr file.
  3. Set the C drive as active : You can do this from disk management or using diskpart
  4. Reboot the server
  5. Open disk management and make sure the C drive is marked as SYSTEM.
  6. Try the P2V process again and this time it should work fine

Obtained from this link


Deshabilitar IPv6 en Windows Server

IPv6 está habilitado por defecto en Windows Server 2008. Normalmente no es necesario tenerlo activo, en instalación completa (full) es fácil, simplemete se desmarca IPv6 en los adaptadores que tengamos en cada conexión de red, pero en versión core, se nos complica un poco.  Para deshabilitar IPv6 en cualquiera de las versiones lo que tenemos que realizar es un pequeño cambio en el registro de windows a tráves de la herramienta regedit:

Necesitamos crear un nuevo valor en la siguiente ruta:


Ejecuta “regedit” y busca el registro HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters ,en la carpeta Parameters creamos una nueva clave de tipo Valor de DWORD de 32 bits, en el panel derecho, click derecho y selecciona New – DWORD, poner como nombre de atributo “DisabledComponents”, luego hacemos click derecho del ratón, modificar y le asignamos el valor “FF”; una vez realizado, reinicia el equipo para que los cambios se hagan efectivos. Si mas adelante requieres habilitarlo tan solo borra la entrada añadida en el registro y reinicia el equipo.

Esto básicamente nos sirve porque la mayoría de nosotros utilizamos tráfico de red IPv4 y el IPv6 lo tenemos activo pero sin ninguna utilidad, también se deshabilita porque a veces suele ocurrir que tenemos es tráfico de la red a través de un Firewall que monitoriza sólo el tráfico que pasa a través del IPv4 dejándo un gran agujero de seguridad en el protocolo IPv6.

Tambien es valido, y más comodo, “ejecutar como administrador” el siguiente comando:

reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 255

reg query HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters /v DisabledComponents

Última actualización 05/03/2023 13:36