|BizTalk HTTP/Web Proxies||Friday 25th April 2014|
BizTalk has a number of different Adapters that transmit over HTTP - and some companies are insistent on putting HTTP proxies in the way of communication. The BizTalk adapters all support the notion of authenticating HTTP proxies, which means this isn't an issue.|
Well - this shouldn't be an issue. It is an issue when you don't always have the need for a proxy, e.g. you have one port that sends out to an external web-server and another that is local and inaccessible to your web-proxy. It seems that the proxy information is shared amongst adapters and ports - and if they don't match, things can get messy very quickly.
I have learnt a major distrust for the proxy configuration tab on the Send Port themselves, instead only use the proxy configuration listed on the adapter handler for that host. And it is with this you can work around the problem. Create a secondary host purely for the purpose of hosting differently configured HTTP-based connections.
I have left the default BizTalkServerApplication's send adapters to not use a proxy server and then created a ProxyHost which has send adapters with proxy configuration setup.
Don't forget you need to create a host instance and reassign your send ports to the appropriate host. And of course, restart your host instances for the changes to be picked up.
As an untrusting computer user, I also make sure that there is no proxy configuration for the current user, which can be done by running Internet Explorer under the credentials of your host instances and disabling any proxy settings.
|Sony Vaio S13 - Windows 8.1 function keys||Saturday 12th April 2014|
I have just updated my laptop to Windows 8.1, and naturally some things stopped working - mostly the laptop specific functions. Such as the light sensor, brightness controls etc.|
I have a Sony Vaio S13 - one of the things that needs to be installed for all this to work is Sony's Firmware Extension Parser. This is listed as a HID (Human Interface Device) in Device Manager. Updating it though, appears to be easier said than done.
Obviously the first port of call, is downloading the driver. The snag comes when you try to execute it - for me (which might not mean everybody), I have a CPU core max out and not a lot else happen. The culprit process is a Command Prompt (cmd) process. Leaving the laptop for an unreasonable length of time see no sign of completing.
Instead, you can install it manually. When running the driver installer the files will be extracted into your temporary directory in a sub-folder with a random name. To find it, run "%temp%" and you will get your temporary directory, find the most recently modified folder. Go into that folder and copy the full path from the address bar.
Then, from Device Manager select to update the driver - if you have uninstalled the previous driver it will be an unknown device (ACPIVEN_SNY&DEV_5001). Select to search for a driver manually and use the path of the folder you copied previously. Windows will then install the driver directly.
Reboot and you should have working buttons again. Of course, make sure things like Vaio Control Centre is updated.