I don't know that anyone intentionally reads my blog versus just stumbling across it when they are searching the web. In either case I have been meaning for a while to post simple articles about products or services that I purchase. These posts won't typically be SharePoint related (could be), but instead will be about general around the house stuff.
My reasoning for wanting to do this is that I have purchased a lot of stuff for my house and family over the years and typically during that process I often wish I had an honest review of the product I was interested in. Sometimes I found them in places like NewEgg, Lowes and Amazon and sometimes I did not.
So I figure I will add my drop of experience/feedback/wisdom to the giant pool of the internet so if someone happens to be thinking about the same product/service they have one more piece of information to evaluate with.
Ok enough with the background on with the first write ups....
Hot Link Pro - Remote Control Extender by Microsmith
I bought this so that we can achieve TV wall hanging nirvana. (aka TV on the wall with no visible cords, input devices, etc.. showing at all despite the TV being hooked to multiple input devices.)
One critical part of the aforementioned goal was hiding all those devices in a closet, but when you do that the remote controls don't work. So that is where the Hot Link Pro comes in...
It has an eye that catches all the remote control signals from your various remotes. It then sends the signal through a single, thin and flexible ribbon of cords. Each cord in that ribbon (6) can then be positioned in front of a devices.
The basic unit (what I have) supports up to 6 devices and that was plenty enough for us.
Opinion
I like this product and it works well although my TV (Samsung LN40B640) puts out a bunch of IR traffic that causes the receiving eye to be "jammed" for a few seconds. Then they eye/TV get in synch (our out?) and everything works well.
I remotely control two devices currently with this unit:
- Tivo HD
- Sony DVD/VHS player
Overall I am very happy with this product and the only downside is that you have to take some time getting the eye in the right spot (with some TVs) so that it does not get false positive IR traffic/noise from the TV itself.
I looked at lots of options (wireless radio remotes, universal remotes, etc..) and settled on this one for it's simplicity, cost and effectiveness and it has worked out well.
Wednesday, February 10, 2010
Sunday, February 7, 2010
Windows Vista/Windows 7 Prompting from Office when Opening Files from SharePoint
This one has been posted elsewhere but I feel like it is worthy of posting again as it is one of those little annoyances.
The Problem
You have Windows Vista/Windows 7 as an OS you have a SharePoint web site (web application for you SharePoint nerds) you access via Integrated Windows authentication (NTLM). You have the website listed in your Local Intranet Zone in Internet Explorer and when you browse the site from the web browser it automatically logs you in using your windows domain credentials. So far so good all is working as expected.
Here are the negative symptoms:
- When you attempt to edit/open a Word, Excel, PPT, etc... file for the first time from the browser you get prompted for authentication even though Word/Excel etc... should automatically log you in.
- In Windows 7 you attempt to use one of the handy new jump list recent file shortcuts (is that the feature name?) from the task bar for a file from SharePoint and it does not load the application/file.
Solution
Follow the steps in KB http://support.microsoft.com/kb/943280 to create a registry entry that will allow the web client service (used by Office applications) to pass your credentials to SharePoint for authentication.
It seems there are lots of these little work arounds these days as more security lock downs are affecting SharePoint communications. They are a necessary evil I just wish that they were publicized better by Microsoft.
Side Note
Another very frequent issue I run into in a simliar vein is with Denied Access messages on the SharePoint servers when you attempt to browse or programatically access SharePoint Web Applications whose names are not the same as the NETBIOS or FQDN of the host server. Which is quite common. For example from the server you can browse to RICDXX01.yourdomainname.com just fine but if you attempt to browse to customportalname.yourdomain.com it is blocked because of a security patch to prevent malware spoofing of FQDN addresses. I have seen this on Windows 2003 & 2008... For more information see this KB http://support.microsoft.com/kb/926642 which I know seems like it is unrelated but it is not.
Also please heavily consider using the BackConnectionHostNames option as a preferred (more secure) way to go. The other option (disable loop back check) is referenced in lots of SharePoint blogs but it turns off all the good checking aspects of the security patch. Applying the BackConnectionHostNames registry setting has become a standard part of my SharePoint setup instructions these days as the issue is almost bound to creep up if you don't.
Almost forgot one final point where this issue will really bite you is in the Indexing (and perhaps other) server run web traffic browsing programattic jobs. I mention this because you can be experiencing this issue and not know it because hitting the site from a web browser not on the server will complete just fine. Meanwhile every time your search & indexing process wakes up (since it runs it's requests from the server) it is failing to crawl content for any of the web applications whose FQDN names (url) are not the same as the machine.
The Problem
You have Windows Vista/Windows 7 as an OS you have a SharePoint web site (web application for you SharePoint nerds) you access via Integrated Windows authentication (NTLM). You have the website listed in your Local Intranet Zone in Internet Explorer and when you browse the site from the web browser it automatically logs you in using your windows domain credentials. So far so good all is working as expected.
Here are the negative symptoms:
- When you attempt to edit/open a Word, Excel, PPT, etc... file for the first time from the browser you get prompted for authentication even though Word/Excel etc... should automatically log you in.
- In Windows 7 you attempt to use one of the handy new jump list recent file shortcuts (is that the feature name?) from the task bar for a file from SharePoint and it does not load the application/file.
Solution
Follow the steps in KB http://support.microsoft.com/kb/943280 to create a registry entry that will allow the web client service (used by Office applications) to pass your credentials to SharePoint for authentication.
It seems there are lots of these little work arounds these days as more security lock downs are affecting SharePoint communications. They are a necessary evil I just wish that they were publicized better by Microsoft.
Side Note
Another very frequent issue I run into in a simliar vein is with Denied Access messages on the SharePoint servers when you attempt to browse or programatically access SharePoint Web Applications whose names are not the same as the NETBIOS or FQDN of the host server. Which is quite common. For example from the server you can browse to RICDXX01.yourdomainname.com just fine but if you attempt to browse to customportalname.yourdomain.com it is blocked because of a security patch to prevent malware spoofing of FQDN addresses. I have seen this on Windows 2003 & 2008... For more information see this KB http://support.microsoft.com/kb/926642 which I know seems like it is unrelated but it is not.
Also please heavily consider using the BackConnectionHostNames option as a preferred (more secure) way to go. The other option (disable loop back check) is referenced in lots of SharePoint blogs but it turns off all the good checking aspects of the security patch. Applying the BackConnectionHostNames registry setting has become a standard part of my SharePoint setup instructions these days as the issue is almost bound to creep up if you don't.
Almost forgot one final point where this issue will really bite you is in the Indexing (and perhaps other) server run web traffic browsing programattic jobs. I mention this because you can be experiencing this issue and not know it because hitting the site from a web browser not on the server will complete just fine. Meanwhile every time your search & indexing process wakes up (since it runs it's requests from the server) it is failing to crawl content for any of the web applications whose FQDN names (url) are not the same as the machine.
Subscribe to:
Comments (Atom)