|
12/14/2009I was having a neat little problem where I was unable to login to WSS sites on my development virtual machine. I would keep getting prompted and prompted for credentials even though the credentials belonged to the admins group. This was a particularly painful issue given that some of the web parts were failing with the wonderful “non-specific error.” After a little scouring I found this little registry hack (Method 1) which fixed the problem: -
Set the DisableStrictNameChecking registry entry to 1. For more information about how to do this, click the following article number to view the article in the Microsoft Knowledge Base: 281308 Connecting to SMB share on a Windows 2000-based computer or a Windows Server 2003-based computer may not work with an alias name - Click Start, click Run, type regedit, and then click OK.
- In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa - Right-click Lsa, point to New, and then click DWORD Value.
- Type DisableLoopbackCheck, and then press ENTER.
- Right-click DisableLoopbackCheck, and then click Modify.
- In the Value data box, type 1, and then click OK.
- Quit Registry Editor, and then restart your computer.
Curiously the login problem didn’t exist with the Central Admin site. 9/4/2009So one day I need to remote into my home server from the other room and could not get in. I tried logging in from both a desktop and laptop and got nothing more than an obscure network error. I searched google thinking that this was a pretty common problem (it is) and that there would be a fairly standard fix (there isn’t). I finally gave up and scoured the event logs, finding this little piece of errata: The RDP protocol component "DATA ENCRYPTION" detected an error in the protocol stream and has disconnected the client. And after dropping that into google I found this fix: Click start—>Run type regedit click ok Locate and then click the following registry subkey HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\TermService\Parameters
Under this registry subkey, delete the following values • Certificate
• X509 Certificate
• X509 Certificate ID Quit Registry Editor, and then restart the server. I’m not sure what the problem was but I’m now able to connect to the server via remote desktop. 8/1/2009<PreRamble> I had a little episode with my notebook this past week which caused me to lose total faith in it. It’s a little warm in this neck of the woods lately and my notebook has always run on the warm side. The fan was always constantly running on full blast (which caused me to get a desktop PC last year so I wouldn’t have to listen to it while working out of the house). This week the notebook shut down hard on me and would not come back on until I plugged it into a different power supply. It has since resumed working with either of my power supplies for it… after a couple faulty bootups and a rather length scandisk session. Needless to say I don’t trust it now and would be up a rather unsanitary river without a paddle if the thing were to die while I was onsite at a client. </PreRamble> So I went out and purchased a new Sony laptop which has a whopping 6 GB of RAM, 400 GB hard disk, and dual flux capacitors or something like that. To take advantage of that copious amount of memory the laptop has Vista64 installed on it. I’ve been installing my stack of software on the past few days and everything seemed to be working pretty well. I did not realize how well the backwards compatibility of 32 bit apps worked on Vista64 until I went to install the final piece of the puzzle, the CISCO VPN client which I use to connect to a couple of my clients. The installation package did not quite get going, and after a little research I find that it indeed does not work on Vista64, period. No sweat, I thought, I’ll just find out how to get the 64 bit version of the client. It turns out that in order to get the 64 bit version of the client I will have to write it, because it does not exist nor is it going to exist anytime in the near future: Cisco VPN Client Version 5 is available for 32-bit Windows Vista. There are no current plans to provide 64-bit support for the Cisco VPN Client but 64-bit support is available for the Cisco AnyConnect VPN Client. The AnyConnect client, it turns out, does not support IPSec which is what my clients use. From the comments I scoured it turns out that a lot of people are using IPSec and are therefore also hosed when 64 bit Windows starts taking over machines. Wow. Scouring comments did lead to a solution, though. A company called NCP Secure Communications sells a universal IPSec client that works on Vista 64. I was able to install a trial version of the client, reboot, import the PCF profile files from the CISCO VPN installation, and fire the connections right up. The software has a lighter footprint than the CISCO client as it doesn’t add another network connection to the list of network devices in Vista. Nor does it seem to be plagued with that weird connection error which happens every once in a while with the CISCO client on Vista 32. The only downside is the $144 dollar price tag. I’m not quite sure why CISCO is abandoning their VPN product on Vista 64, other than to force their customers to purchase new hardware that will work with the AnyConnect client. 7/16/2009If you've ever done a fresh install of Win2k3, then the service packs, then installed IIS, then installed WSS 3.0, then fired up Central Admin, get barraged by security challenges and finally end up pretty much with a worthless Central Admin... Try re-applying the service packs, especially if you installed IIS from media that pre-dated the service packs you just installed. I don't know what the exact problem is, but the symptoms probably aren't limited to WSS. One of the files that will fail to authenticate is WebResources.axd, which can be utilized by any ASP.Net application. I can imagine a few people have run into this but I only found one page which described the symptoms and solution. 6/9/2009Um, wow. Google today releases Apps Sync for Microsoft Outlook. It unfortunately only works with Educational and Premier Edition users (Premier costs 50 bucks per user per year) but now gives you complete, Exchange-like sync between Outlook and Google's servers. What this means for a freelancer like me is that I now have robust, offline access to my email, contacts, calendar, and (I presume1) tasks. I'll also have my email "backed up" locally, and I can now competently sync my google data to my Windows Mobile device without running a couple of half-baked sync services. Interestingly enough, I'm currently watching Outlook create email folders through the sync process using all the labels I've created in gmail. [1] Tasks have always been kind of flighty in google apps, and I haven't seen any hit my Outlook yet during the initial sync process... although it's still running.
UPDATE #2: Bummer, no tasks sync. Yet. Hopefully this will get implemented in the not-too-distant future.
UPDATE #1: Well, I should get comfortable seeing my contacts on my phone sorted by first name since google doesn't do the firstname/lastname thing. That and seeing all the extra cruft google considers a "contact," such as everything in the "all contacts" lists which is comprised of everyone you've written to but haven't added to "My Contacts." 4/14/2009I've been struggling over the past year with connecting to off-network sites when firing up a connection to a client's network via the Cisco VPN client. Once the connection was established I could get onto the client's network resource alright but could only get to a scant few outside websites. That's a little difficult when working on an intranet site for the client and needing to research something (which I am constantly doing). This was only happening on my desktop machine. My laptop connected just fine. I logged both of them in at the same time and went through every conceivable setting for the Cisco VPN adapter, the physical network adapter it was piggy-backing on, and the VPN client itself. Vista Home is running on the desktop, Vista Business on the laptop. The only other difference was the network hardware itself -- wireless on the laptop, ethernet on the desktop. That is, until I double checked the version numbers of the client -- 5.0.00.0340 on the laptop, 5.0.03.0530 on the desktop. I had upgraded the version on the desktop some time ago due to some weird bug with the VPN client in Vista where the client would work a few times and then absolutely refuse to connect afterwards, getting to the "securing communications channel..." phase before bailing out. The new version of the client fixed this problem, but also apparently fixed-up off-network connectivity. After downgrading to the prior version of the client, voilà, I can get on their network and public websites at the same time. The original bug can be worked around be resetting the Cisco VPN adapter in the network connections window. When disconnected, enable the connection by double clicking on it, then right-click on it and select diagnose. Select the reset option at bottom and it seems to fix itself. |
|
|
|
|
|