Concatenating arrays in PHP

Use array_merge to concatenate two numerically-indexed arrays; not array_push and not the array union operator: +.

$first = array('doh', 'ray', 'me');
$second = array('fah', 'soh', 'lah', 'te', 'do');

echo "Union: ", var_export($first + $second, true), "n";
echo "Merge: ", var_export(array_merge($first, $second), true), "n";

// array_push returns int, not an array:
array_push($first, $second);
echo "Push: ", var_export($first, true), "n";

The output:

Union: array (
  0 => 'doh',
  1 => 'ray',
  2 => 'me',
  3 => 'te',
  4 => 'do',
)
Merge: array (
  0 => 'doh',
  1 => 'ray',
  2 => 'me',
  3 => 'fah',
  4 => 'soh',
  5 => 'lah',
  6 => 'te',
  7 => 'do',
)
Push: array (
  0 => 'doh',
  1 => 'ray',
  2 => 'me',
  3 =>
  array (
    0 => 'fah',
    1 => 'soh',
    2 => 'lah',
    3 => 'te',
    4 => 'do',
  ),
)

IIS 7: Failed Request Tracing Rules

Overview

Failed Request Tracing Rules is a powerful tool for troubleshooting request-processing failures in IIS 7.0.  This topic leads the reader through the steps to enable Failed Request Tracing Rules to debug failures and trace steps in Application Request Routing.  For more information about Failed Request Tracing Rules, refer to this article.

Goal

To configure Failed Request Tracing Rules and to understand what to look for when troubleshooting Application Request Routing.

Prerequisites

This walkthrough requires the following prerequisites:

• IIS 7.0 on Windows 2008 (any SKU) or newer with Tracing role service installed for IIS.
• Microsoft Application Request Routing Version 1 and dependent modules.
• Minimum of two application servers with working sites and applications.

If Application Request Routing Version 1 has not been installed, it is available for download at:

• Download Microsoft Application Request Routing Version 1 for IIS 7 (x86) here.
• Download Microsoft Application Request Routing Version 1 for IIS 7 (x64) here.

Follow the steps outlined in this document to install Application Request Routing. 
Another prerequisite is that the reader has gone through the other walkthroughs and has configured Application Request Routing.  Application Request Routing should be in working order before proceeding with this walkthrough.

Step 1 – Configure Failed Request Tracing Rules

In this step, the Failed Request Tracing Rules are defined for Application Request Routing.
To configure Failed Request Tracing Rules using the UI:
1.  Launch IIS Manager (inetmgr).

2.  Select the Default Web Site.

3.  In the Actions pane, under Configure, select Failed Request Tracing….

4.  In the Edit Web Site Failed Request Tracing Settings dialog box, check the Enable checkbox.

5.  Click OK to save changes.

6.  Select the Default Web Site.

7.  Double-click Failed Request Tracing Rules.

8.  In the Actions pane, click Add….

Select All content (*), and then click Next.
9.  Select Status code(s): and enter 200-399.

Click Next.  The above configuration has created a Failed Request Tracing Rule that writes traces when the status code falls between 200 and 399.
10. Deselect ASP, ASPNET, and ISAPI Extension.  After selecting WWW Server, deselect everything under Areas:, except for Rewrite and RequestRouting.  Since Application Request Routing relies on the URL Rewrite Module to inspect incoming requests, it is recommended that you enable the traces for both Application Request Routing (RequestRouting) and URL Rewrite Module (Rewrite).

For additional information about URL Rewrite Module traces, refer to http://learn.iis.net/page.aspx/467/using-failed-request-tracing-to-trace-rewrite-rules/.
11. Click Finish.

To configure Failed Request Tracing Rules using the command-line:
1.  Open a command prompt with administrator privileges.
2.  Navigate to %windir%\system32\inetsrv.
3.  To enable Failed Request Tracing on the Default Web Site, enter: appcmd set site "Default Web Site" -traceFailedRequestsLogging.enabled:"true" /commit:apphost.
4.  To configure the Failed Request Tracing Rules as shown in the UI above, enter:

• appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /+"[path='*']"
• appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /+"[path='*'].traceAreas.[provider='WWW Server',areas='Rewrite,RequestRouting',verbosity='Verbose']"
• appcmd.exe set config "Default Web Site" -section:system.webServer/tracing/traceFailedRequests /[path='*'].failureDefinitions.statusCodes:"200-399" 

Step 2 – Analyze Failed Request Tracing Logs

In this step, you will send requests to Application Request Routing and analyze Failed Request Tracing logs.
To view Failed Request Tracing logs:
1.   Navigate to the directory where the Failed Request Tracing logs are written.  By default, the location is %SystemDrive%\inetpub\Logs\FailedReqLogFiles\.

2.   Change directory to the folder that matches the Default Web Site.  By default, this is W3SVC1.  If you are unsure, select the Default Web Site in IIS Manager, and then select Advanced Settings… in the Actions pane.  The value of the ID indicates the corresponding folder.  (ie. ID 1 corresponds to W3SVC1).

3.   If there are any xml files, remove them by typing:
            del *.xml
4.       Send a request to Application Request Routing.  If Application Request Routing is functioning correctly, it results in a 200 response, which falls within the 200 to 399 range that was specified in Step 1.  Therefore, the logs are written to the location above.

5.       List the files in the directory to confirm that new xml files are written.

6.       Open the xml file.  Click Request Details.  Select Complete Request Trace, and then click Expand All.  Below is an example of a Failed Request Tracing log for Application Request Routing:

7.       Pay closer attention to the following sections:

• GENERAL_REQUEST_HEADERS:
  •  Headers: Shows the HTTP header that Application Request Routing has received.

•  ARR_REQUEST_ROUTED:
  • WebFarm: Indicates the name of the server group to where the request is routed.
  • Server: Indicates the destination server to where the request is routed.
  • Algorithm: Indicates which load balance algorithm is used.
  • RoutingReason: Indicates the decision behind why the server is selected.

• ARR_SERVER_STATS:
  • State: Availability of the destination server.
  • TotalRequests: Runtime statistic on how many requests have been sent to this server.
  • CurrentRequests: Runtime statistic on the concurrent number of HTTP requests to this server.
  • BytesSent: Runtime statistic on how much data in KB have been sent to this server.
  • BytesReceived: Runtime statistic on how much data in KB have been received from this server.
  • ResponseTime: Runtime statistic on the responsiveness in ms of this server.

• GENERAL_RESPONSE_HEADERS
  •  Headers: Shows the response HTTP header from the destination server.

• GENERAL_RESPONSE_ENTITY_BUFFER
  • Buffer: Shows the response entity from the destination server.

• The following have been added with the timestamps to indicate the start and end times of corresponding events to profile the performance of Application Request Routing:
  • ARR_REQUEST_HEADERS_START
  • ARR_REQUEST_HEADERS_END
  • ARR_RESPOSE_HEADERS_START
  • ARR_RESPONSE_HEADERS_END
  • ARR_RESPONSE_ENTITY_START
  • ARR_RESPONSE_ENTITY_END
  • ARR_RESPONSE_ENTITY_START
  • ARR_RESPONSE_ENTITY_END

If you are collecting the Failed Request Tracing logs on server core, you must copy the logs with freb.xsl stylesheet to a computer where a browser is available.

Summary

You have now successfully configured Failed Request Tracing Rules for Application Request Routing.  Failed Request Tracing Rules can be used to troubleshoot and debug Application Request Routing, as well as understand the routing decisions, including load balance algorithms, that it has made in selecting the destination server for a given request.

Windows Server 2008 R2 FTP and Firewall Setup

 Install the Web Server role with the IIS Management Console and FTP Server role services:
 

 

Create a new FTP Site:
 

 

Setup the site with the default bindings and choose Allow SSL if you don’t plan on deploying a certificate:
 

 

Configure user permissions and basic or anonymous permission.  If your server is connected to your domain you can specify domain users, otherwise they must be local user accounts:
 

 

Finally you’ll have to configure your server’s firewall rules to allow access.  Personally, I think Microsoft’s done a great job up until this point… it’s a shame it couldn’t last.  Disregard any existing FTP firewall rules; although they should be enabled, they don’t actually allow access!  Run Allow a Program Through Windows Firewall and grant access to C:\Windows\System32\svchost.exe
 
 

Smarty: check string containing

{if $string_val|strstr:"seeked_str"}

vtiger 5.3 - Outlook Plugin 2.1 - Installation Problem

Removed all the .NET, and only installed the last one, .NET framework 4. But it seems it does'nt replace the older versions, all frameworks are complementary.

1 Installation of the .NET Framework 2.1 and 3.5 versions, all needed for VTiger.

2 Then, I installed the Microsoft Office 2010: Primary Interop Assemblies Redistributable

3 Plugin 2.1 installation

4 If the plugin don't show, then try to go in the Trust Control center and activete it. If it does'nt start, follow step 5.

5 Replace the OFFICE.DLL and Microsoft.Office.Interop.Outlook.dll into the plugin folder by the one mentionned by lsmonki. Restard outlook, and if the plugin does'nt show by itself, go activate it in the Trust Control Center. It should start now.

And as a bonus, here's some things you can do to troubleshoot the plugin startup process if this procedure does'nt work for you. I hope this will be as usefull for you as it was for me.

1 - activate fusion login. Open regedit and in the node HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion add the following keys :
- DWORD EnableLog with value 1
- DWORD ForceLog with value 1
- DWORD LogFailures with value 1
- String LogPath with value a directory of your choice, don't forget to create it (e.g. c:\tmp\fusion)

2 - try to load the extension with a simple VB script. Create a file names addin.vbs and edit it with the following content :

set o = CreateObject("vtigerCRMOutlookAddin.Connect")

Execute it, then go to the log folder created above, there may be files created with usefull infos in case of failure.

3 - activate logging in Outlook by creating the following environement variables :
- VSTO_LOGALERTS with value 1
- VSTO_SUPPRESSDISPLAYALERTS with value 0
Restart outlook and try to activate the plugin. It should display usefull error messages.

Remote Desktop: copy file to local computer and vice versa

 Start up a remote desktop dialog.

Then expand the dialog by clicking on Options, then check the Local Resources tab.
Make sure Clipboard is checked, and then hit the More… button.

Now you can select a local disk to be shared with the remote machine. For example, in this case I selected my C: drive.
As you can see in the screenshot, the file explorer has another drive named “C on HAACKBOOK” which can be used to copy files back and forth from my local machine to the remote machine.
But here’s the part I didn’t know. Let’s take a look at the desktop of my remote machine, which has a text file named info.txt.
One way I can get that file to my local machine is to copy it to the mapped drive we saw in the previous screenshot.
Or, I can simply drag and drop the info.txt from my remote desktop machine to a folder on my local machine.

So all this time, I had no idea cut and paste operations for files work across remote desktop. This may be obvious for many of you, but it wasn’t to me. :)