|
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/23/2009One of the most annoying things for me when working with Visual Studio is that CTRL-W does not close the current window. Just about every other app does it, even SharePoint Designer. WHY OH WHY?! I know I can CTRL-F4 but I have to reach an extra two inches with my left index finger to do that, and when you extrapolate that over several billion times you could have reached the moon. And by that time I'm quite certain I would have sprained something. AutoHotKey to the rescue. It's a wicked powerful macro/keystroke recorder/automation utility, and I've been using it to "patch" keyboard deficiencies with apps I work with. For Visual Studio: #IfWinActive ahk_class wndclass_desked_gsk
^w::send ^{F4} It has its own comprehensive scripting language but doesn't leave you out in the cold trying to figure it out. The help file that comes with it details everything to the utmost degree. It runs in your system tray and can execute keystrokes anywhere you please or only for specific applications (such as the example above). 4/21/2009And by berserk I mean something along the lines of pegging a CPU core out at 100% and not coming back... generally accomplished when switching from code to design view, or alt-tabbing back from another application to SPD when it's in design view. - Having a DataView on the page. Your chances of SPD going into berserk mode increase if a) you have more than one DataView, b) the DataView has information joined from multiple lists, and c) you are previewing with sample data rather than "faked" data.
- Having script blocks with code inside them (rather than using the src attribute). It doesn't matter if they are run on the server or the client.
In instance 1 I can go a fairly long time between crashes, especially if I try to make sure I use faked data. In instance 2, if I'm working on the same page and alt-tabbing back and forth between the browser and SPD, I can crash SPD pretty much at-will in a few minutes. 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. 3/11/2009Howdy.
I've decided to fire this blog up to publish ideas, links, and other items of interest related to my business. Hopefully you'll find something useful here.
I have a handful of posts I'm planning on migrating from one of my other blogs, Idiotsyncrasies, a treasure trove 1 of general information.
One last note -- this blog is built on WSS 3.0, also known as the poor-man's version of SharePoint. I've hacked it up a bit so it's presentable but there are going to be rough edges until I have time to address them.
[1] And when I say treasure I mean that in a one-man's-treasure-is-another-man's-garbage sort of way. |
|
|
|
|
|