Placing RC4 cipher to top of the list fixes the FTP-SSL file upload problem (“550 The supplied message is incomplete” response to uploads) with IIS7 & 7.5.
(same as one of the fixes in : http://blogs.msdn.com/b/kaushal/archive/2011/10/03/taming-the-beast-browser-exploit-against-ssl-tls.aspx Move “TLS_RSA_WITH_RC4_128_SHA” to the top of the priority list.)
Unfortunately the given method for doing this (Group Policy) is non workable due to the 1023 char limit in the group policy value field.
Use IIS Crypto to make the job easy peasy. Now FTP-SSL uploads work.
This is the dude behind Xataface.
I love people who create and give great open source software to the world.
Xataface looks to be exactly what I was searching for. Like DabbleDB but better, self-hosted, and still here. Thanks Steve!
Nightmare. I have come across this twice now, and really struggled to figure out what’s going on. In both cases it was apparent that the problem was specific to the particular user – i.e. another user on the same computer was fine.
I tried the offline setup, and even the enterprise MSI setup – still will not launch chrome.exe
Well, I figured it out. It’s caused by a user-mode rootkit. This particular user did not have local admin rights on his computer so I guess that’s the only sort of rootkit that could take hold.
The computer had a history of some virus infection, with ESET v4 half-blocking a zbot.aoo infection.
Running malwarebytes, gmer, eset v4, zbotkiller as Administrator didn’t achieve much.
Running zbotkiller.exe (kaspersky) as the affected user found something, and then again another time, but problem still persisted.
Running GMER as administrator turned up nothing. Running GMER as the user turned up something of interest (“telnet server” hidden service or something). Problem still persisted though.
In the end, because it’s a user-mode rootkit, I rebooted, logged on as a different user (local admin), and loaded the affected user’s NTUSER.DAT profile into regedit, then browsed to his Software->Microsoft->Windows->CurrentVersion->Run key and removed about three offending entries from there.
All seems OK now.
Changing the actual username, i.e the username that gets automatically sent to file servers, is not straightforward in Home edition at all.
Required for network logons without password prompt. If the username and that user’s password matches what is on the server, then there is no pop-up prompt for username/password.
Renaming in User Accounts only changes the display name.
Start -> run -> “control userpasswords2″
then choose properties on the user, and change the username there
This time, an RB751G-2HnD is acting as a wireless station (client), and a PPTP VPN client, allowing a Polycom SoundPoint IP phone to work from a remote location, through a VPN, wirelessly.
The Mikrotik connects to the WiFi in the house, and then it makes a PPTP VPN connection to the remote office. The Polycom phone then connects to the office via this Mikrotik. In effect we are adding WiFi & VPN functionality to a Polycom SoundPoint IP 430. Sweet!
The Mikrotik is making use of a simple road-warrior PPTP connection (Microsoft RRAS). It is performing NAT over the VPN connection’s single IP address.
Office 365, Outlook 2010 horrible performance, shared mailboxes, calendars, slow, hangs and freezes. Connection to Exchange server unavailable.
(I just copied my post from the Microsoft forums here). Original thread: http://community.office365.com/en-us/forums/160/p/62614/261211.aspx
This problem was due to the number of concurrent HTTPS connections used by Outlook-Anywhere, especially in the case of shared calendars, shared mailboxes, and delegated access. The problem is exacerbated by the fact that users are randomly placed at different server locations (various servers within Dublin and Amsterdam for EMEA users). I opened a case to try to get all the users put on the same mailbox sever/cluster, but that wasn’t possible. I began re-creating uses repeatedly in an attempt to get them all in the same location, but I realised I was probably not going to get things improved enough anyway.
The issue was that the broadband, provided by the serviced office building, could not handle those concurrent connections (8 or 9 concurrent HTTPS connections per Outlook client), or was attempting to load balance them or something. I tried and tried and tried to get the building’s “IT lady”, and their IT contractors, to look into restrictions in the number of concurrent connections, or load balancing/proxying, or whatever was wrong at their router/firewall, but I had no joy. They just kept offering more bandwidth, lower contention (1:1), and telling me that there were no restrictions.
Well, in the end, to solve the problem, I bought a hosted-VPN account (£3.99/month PPTP account, as used by people who want to hide/change their location on the web), and configured a Mikrotik router to route all Microsoft destinations through this PPTP service. The customer was delighted at the results. Up until this point, I don’t think they believed me that it actually “normally worked quite fast”.
I set the Mikrotik to establish a connection to the hosted PPTP VPN service, and route the followng CIDR ranges through that tunnel:
I had to route just Microsoft stuff through the VPN, instead of the easier option of routing everything through the VPN (default route to VPN), because it became apparent that quite a few websites didn’t work via this particular VPN provider. I guess they might get blacklisted, or they are low-maintenance (you get what you pay for..). Anyway it was easier than trying other providers, or opening more support tickets, etc.
What this means is that there is only a single connection going out through the broadband for Office 365, for the entire company, thus overcoming the problem.
While it is clear that the broadband is at fault (it is a serviced office building – the customer can not install their own broadband or telephone lines), I think Microsoft should look at either providing VPN access to the Exchange severs, in the same way most of the world used to access Exchage in the pre RPC/HTTP days, or they might look to optimize the number of connections that are used. 9 connections per client is quite high in my opinion.
p.s. Mikrotik = super.
Firmware upgrade fails.
Remove your user & admin passwords from the unit, and try again.
Trouble with DTMF on outgoing calls.
Played with DTMF transit types – AVT is the type we want (RFC2833), but some digits are not being picked up. In particular, the number 2 is very rarely being picked up.
The solution: reduce the FXS input gain (on the System tab at the bottom). It was on -3. I set it to -5 and it looks perfect. The tone signal must have been clipping.
Exchange 2010 GAL problems. address book service will not start – not compatible with the version of windows you’re running.
How very bizarre.
Migrating from Exchange 2003 to 2010 SP2. Somewhere along the way – after uninstalling Exchange 2003, we started having directory / GAL problems. New Outlook profiles could not be set up, and the GAL could not be downloaded into already-working Outlooks.
After some exploration (and fixing some Public Folder related issues ( http://clintboessen.blogspot.co.uk/2011/04/exception-active-directory-user-wasnt.html ) I noticed that the Microsoft Exchange Address Book service was not started. I tried to start it, and found Event ID 7000 from the service control manager, with description
“The Microsoft Exchange Address Book service failed to start due to the following error:
This version of Microsoft Exchange Address Book is not compatible with the version of Windows you’re running. Check your computer’s system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher.”
I looked at the executable path, and went to check out the properties of the file (“C:\Program Files\Microsoft\Exchange Server\V14\bin\Microsoft.Exchange.AddressBook.Service.exe”), and I noticed there were no PE properties / attributes, and also, that the file was only 2kb in size. Actuallly the same size as the .config file alongside it. Weird. I thought I’d take a look inside.
I opened up Notepad, and drag’n'dropped the EXE file into notepad, and sure enough, the .exe file was actually the same as the .config file.
It seems that one of the updates has incorrectly modified the wrong file. It has overwritten Microsoft.Exchange.AddressBook.Service.exe with what should instead be in Microsoft.Exchange.AddressBook.Service.exe.config.
The server started out as Exchange 2010 RTM, then it had SP1 applied, and then SP2. This problem was noticed shortly after SP2.
I dug out the correct .exe file from the SP2 extracted files, under setup\serverroles\common, and replaced it, then started the service. All is now well again.