While opening files in Explorer to a connected SharePoint Document library, you may receive a warning that action is unsafe, etc. The fix to this for network drives is to add them to the Intranet sites in Internet Settings. It isn’t clear how to do this for SharePoint as using SSL gives you a address such as \\sharepoint@SSL\davwwwroot\. Adding this site to your list just results in it storing SSL as an address rather than the full address you want (i.e. sharepoint@SSL). The fix is simple, just use registry
Windows Registry Editor Version 5.00
I’ve directly added sites to my intranet sets in the past before with registry. It is how I manage my company so users can still modify their trusted sites, but I can inject the proper trusted/intranet sites they need for things to work.
I stumbled across a weird issue with Dynamics CRM 2011. I thought it was due to Rollup 12 as it only recently started happening, but it appears to be default behavior (whether I noticed it before or not). Basically the steps to reproduce this are very simple.
- Create a case with some basics
- Add some notes
- Add the case to the queue
- Access the queue
- Click Assign in ribbon
- Assign case to yourself.
- Save and close.
After a short while the case notes that once where owned by User A, now are owned by User B. Thats not what I expect to happen. I expect the notes to stay the same.
Well it appears there is a simple work around to this. Although not what I wanted to change, this does get around it.
- Go to Settings -> Customizations -> Customize this system
- Navigate to Entities -> Cases -> 1:N Relationships
- Open Notes
- Change Relationship from Parent to Cascading.
- Change the Assign from All to None
- Save and close
- Publish all Customizations (may not be needed but just to be sure)
Doing more testing with CRM 2011 Rollup 12, I found out that Chrome was self closing when I logged into CRM. This is very annoying, but having worked with CRM before in IE, I knew what this was. By chance I was able to verify it by going to the CRM url and changing the last part of the url to /main.aspx. I got a notification that a popup was blocked. Sure enough, after I added the crm address to the popup blocker exception list, no more self closing windows.
Update 2/14/13: Also should note that this affects Safari as well. Popupblocker’s cause quite a problem with CRM and there is no notification what it is about to do. I find the fact that CRM needs to launch into its own window a pain. I personally have it in a pinned tab in Chrome. I don’t worry about it and when I need CRM its there and not on some other obscure window.
While testing out CRM 2011 Rollup 12, I noticed that I could not get it to log me in for Chrome. After checking my security log and resetting Chrome back to defaults, it still didn’t shed any light onto why this was happening.
After much searching, I happen to find the article explaining this. http://support.microsoft.com/kb/2709891/en-us?sd=rss&spid=15707
While this requires a registry edit and supposedly opens up a man in the middle attack, it does indeed fix it. Hopefully a proper fix comes out in the near future to resolve this properly. In the mean time this works well.
This one has been bugging me for a while. I had a CIFS based ISO share. For some reason the share would fail to update now and then with the error message “The specified storage repository scan failed”. A restart of the CIFS system would fix it, but none the less it wasn’t a solution. Other google results mostly pointed to NAS/SAN issues and not a CIFS share issue. I thought that the windows system was to blame because of the connections limit it has on non server editions.
While I was manually browsing the CIFS share I noticed something. There was a file on the share with a file name being a UUID. The file contained nothing and I checked and sure enough I was getting this error at the time. So I copied it somewhere else and deleted it. A rescan worked without any errors. No more errors and new files show up right away when added to the ISO share.
I was looking for a way to accomplish the need of making it easier for users to access a SharePoint Document Library, with the plus side of being able to add this into a GPO and letting it be mapped across the domain. Of course you can add a network location to a SharePoint Document Library, but I didn’t know of a way to script that via a GPO logon script. I really didn’t research much into that, I figured mapping drives would be easier to explain to users.
It turns out this is really simple to do. The SharePoint server maps it as a WebDav path on a network share. So by using \\SERVERNAME\DavWWWroot\ I got the root of the SharePoint site. From there, I just filled out the rest. Such as \\SharePoint\DavWWWroot\Shared&20Documents links to the Shared Documents library on the SharePoint site.
From that point on, its as simple as using a GPO to deploy this and map the drive.
While configuring Reporting Services on a server running Windows 2008 R2, I came across this issue. After some searching I found out Microsoft has a kb article about this (http://support.microsoft.com/kb/972328), however it mentions only applying to MSSQL 2005. Well the Server I had had MSSQL 2008 R2, as well as SharePoint 2010 and Exchange 2010. It seems that this fix also still works. So if you are confused as to why this is happening and think the article doesn’t apply to you, give it a shot anyways.
I added boot camp to one of my macs and happy found that that Windows 7 supports reading HFS drives. Which means it had access to my Mac OS X installation. Sadly it didn’t keep the user permissions setup and I could see everything from all users. Not acceptable for a family used computer.
So some google searches did bring up some options, however I found that all of them alone don’t resolve the issue completely.
The first thing I found suggested using “gpedit.msc” to add policy in User Configuration -> Administrative Templates -> Windows Components -> Windows Explorer in the “Prevent access to drives from My Computer” policy. However this had two limitations here. First off it applies to the current local user only and secondly it only did drives A-D. Which doesn’t help me with drive E.
Now, I can open “mmc”, go to add a snap in, select Group policy editor, click browse and then the users tab to set it to non administrators. However the secondary limitation was still the problem. I needed to do a non default drive that the group policy editor didn’t support. Which makes it almost useless.
Another solution I found was to modify the windows registry to do this. HKCU\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer may contain a dword called “NoViewOnDrive”. This is perfect for what I want as I can limit it to other drives. A article on how to geek explained how the data was represented. So this works out for me.
However that solution had the same problem as first time where it only the current user. So after more searches not turning up anything useful I found a solution that works. By using the mmc I created above to add a policy for non administrators, it added that data into the registry. I simply used the find function to locate “NoViewOnDrive”. After some searches, I located it.
I do want to mention I did close the mmc I was using and opened the registry editor before. Data may be outdated otherwise and may not update. But it was simple to do this after which as I modified the value to match what I wanted. Now it appears to be working just fine for non administrators and is preventing access to the drive. A little more work than I wish I would of had to do in order to accomplish this, but it got the job done.
There is a similar dword in the registry called NoDrives. This simply hides the drives and does not prevent access to them. I left the drive visible as it really doesn’t bother me to see it. I just needed to prevent its unleashed access to the drive.