Do you want to open this file? We can't verify who created this file.

Yes - I uninstalled Chrome (which removed the desktop shortcut) and re-installed Chrome - but any shortcut created on the user's desktop will cause this warning. Re-installing Chrome just re-creates the desktop shortcut.

This warning was happening before Chrome was installed. Just using about every shortcut on the desktop causes this warning.

Hopefully, IT can figure out why this happens and more importantly, has a cure.

Testing that process in a VM did not work for me - I cannot log on to the profile that was copied over. Perhaps I did something wrong.

Before the video below was made, the VM was restarted to free up the account named username. The user named admin is logged on.



Logging back in as admin, username's profile folder seems fine.

Thanks - that worked. I'll see if I can find a computer that I can try this on. Unfortunately, these computers stay pretty busy. Even finding time for IT to look at them is a problem. And wouldn't you know it, two computers that are not so busy don't have this warning issue.

I had seen that Copy to button before, but I had never explored its use. Thanks for the tip.

This has happened again; but to a different set of 20+ computers.

There was an outage of name resolution services. That broke the folder redirection for IE's Favorites. I fixed that by using the file server's static IP address, but somehow during that minor edit, Windows 7 pro 64bit decided that it needed to assign the user's desktop folder an integrity level of Low. Windows also assigned this Low integrity level to every local or networked shortcut on that user's desktop. The user's Start Menu shortcuts, the "all users" Start Menu shortcuts, the Public desktop folder and shortcuts pinned to the taskbar escaped this mess.

ICACLS does not seem to be able to remove the integrity level. By default, no level is assigned to a user's desktop folder or to most shortcuts on the user's desktop. However, ICACLS can change the integrity level to medium - thus avoiding the security warning.

There is an app floating around that claims to be able to remove the integrity level on folders and files... but I've not tested it. So I won't link to it.

BTW, these computers are running IE9. Look what happened to this OP when he blocked IE9 from getting to its Favorites folder. desktop integritylevel keeps dropping to 'low'

My file used to look like the first image with that Security area and the option to unblock, so I unblocked it, and now it looks like the 2nd image with no Security area (general tab).

Will the registry "allow blocking" restore the Security area with "unblock"? (It's hard to determine if instead it does something else, and I want it to apply only to this one file, or a limited set of files, not system-wide.)

I don't want to run the registry thing until I know it will restore the unblock-ability in this file's Properties.

If the registry change won't restore the Security "unblock" option, how do I restore it? Is it an ACL thing where that info is kept?

We run Win7 Pro as regular users, with IE9. None of us regular users have admin. Admin wasn't required to use "unblock".

PReinie said:

Will the registry "allow blocking" restore the Security area with "unblock"? (It's hard to determine if instead it does something else, and I want it to apply only to this one file, or a limited set of files, not system-wide.)

No registry tweak has been mentioned in this thread. However, I can confidently say that what ever registry change you are referring to, it will implement a system-wide or user account-wide change, and will not be per file.

PReinie said:

If the registry change won't restore the Security "unblock" option, how do I restore it? Is it an ACL thing where that info is kept?

Yes actually. The blocked state of a file is stored in the file's ACL… that is, only if the file is ‘blocked’ using the integrity level method…

There are two circumstances in which Windows will consider a file ‘blocked’: one case involves a file having a low integrity level (integrity levels are in fact stored in an object’s ACL). The alternate way involves a file having a specific Alternate Data Stream named ‘Zone.Identifier’ and containing some particular data. I believe the latter being the more common variety.

Though I’ve never come across one naturally, this thread is concerned with the low integrity level type of blocked file. The difference between the LIL and ADS ways of blocking a file is that LIL-ed blocked files do not allow for an easy way for users to unblock them. That is, there’s no “Always ask before opening this file” check box in these files’ “Open File - Security Warning” dialogues, nor is there an “Unblock” button in their Properties pane. So you can imagine how odd the experience would have been, for people who have been in the OP’s position.


For people who have found this thread looking for a way to un-unblock a file, below is a batch file. Drop a file onto the script and it’ll ‘block’ the given file (using the ADS method).

Code:

:: BlockFile.bat FileName
@echo off
REM Block a file by writing information to it's 'Zone.Identifier' ADS stream. 
if "%~1"=="" echo Missing 1 expected argument&& exit /b
if not "%~2"=="" echo Unexpected arguments&& exit /b
if not exist "%~1" echo File "%~1" does not exist&& exit /b
if exist "%~1"\* echo Unable to block a folder&& exit /b
> "%~1":Zone.Identifier (
    echo [ZoneTransfer]
    echo ZoneId=3
)