Problem when downloading large file in Vista RC1

If you download a large file(over 1GB) by IE7 in Vista RC1. The downloaded file may disappear
from the destination folder after the download finished. The file will instead, be placed in

This problem maybe related to the security feature in IE7. To prevent this problem, you will
needed to run IE by using the "run as" method and use the Administrator account to start IE7.

In this case, large downloaded file will be placed in anywhere that you specificed.


Problem on Vista connect to Linux

From brianwu :

I am using Vista RC1. I found a problem when i connect to my linux server. It prompted me to insert account and pw. After I keyed in the account/pw. It said that my account/password was incorrect.

However, when I was using WinXP connecting to the linux, it worked (using the same acc and pw). I tried to disable the Vista firewall, it also failed..

If i connect from the Vista to the linux using ftp, it worked.

Anyone know the problem?

My Answer:

Hi Brian. MS don't think 3rd party SMB server is safe….so….It encrypt all password send to 3rd party SMB server(linux samba).

You can try to change the local policy to solve the problem:

Configure the "Microsoft network client: Send unencrypted password to third-party SMB server" option to be ENABLE

Configure "Network security: LAN Manager authentication level: Send LM & NTLMv2 session security if negotiated"

can help!

Better Synchronization in Offline File of Vista

Just read a introduction on the change of Offline file in Vista from Navjot Virk, program manager for Offline Files in Windows Vista. I feel it is great and would like to share with yours:

Better Synchronization
Offline Files in Windows Vista offer much improved synchronization. The improvements to synchronization are two-fold. First, Offline Files in Windows Vista uses a new faster algorithm to determine what files or directories are different between the client and the server. Second, Offline Files in Windows Vista uses “Bitmap Differential Transfer” when synchronizing changes from the client to the server. Bitmap Differential Transfer is essentially a mechanism to keep track of what blocks of file were modified when offline. When synchronizing changes from the client to the server, Offline Files in Windows Vista sends only those blocks of the file that were modified offline. In Windows XP, Offline Files always copies the entire file even if only a small part of the file was modified.

Bitmap Differential Transfer makes the synchronization in Windows Vista more efficient and enables Offline Files to cache large files like .pst and .mdb files. Because Offline Files in Windows XP could not synchronize large files efficiently, files like .pst and .mdb were by default not cached. Offline Files in Windows Vista can cache all file types and by default no file types are excluded.

Please note that the Bitmap Differential Transfer in only used when pushing changes from the client to the server. This optimization is not used when pulling changes from the server to the client. If a file is modified on the server when offline, Offline Files in Windows Vista will still copy the whole file down to the client during synchronization. The impact of this will be more pronounced for those users who modify the same files from multiple client computers.

Also, note that Bitmap Differential Transfer only works for pre-existing files that are modified in place. Bitmap Differential Transfer will not happen for files that are created while offline. Some applications, like Microsoft Word, do not modify the file in place. These applications create a new temporary file with the changes and later rename the temporary file to the original file. Bitmap Differential Transfer will not happen for such files.

All improvements to synchronization including Bitmap Differential Transfer will be available against any SMB server, for example, Windows 2000, Windows 2003, Windows R2, NetAPP server, etc. 

Offline Files in Windows Vista also provides per-user synchronization. All synchronization operations only synchronize files that the currently logged on user has access to. Offline Files in Windows XP would always try to synchronize all files in the cache including files that where cached by other users. The logged on user would see synchronization failures for the files that he did not have access to. In Windows Vista, the user will only synchronize his files (files that he has access to) therefore he will never see errors for files that belong to some other users (files that he does not have access to). 

Also, synchronization of Offline Files in Windows Vista can be scripted using WMI.

Windows Update Troubleshooting Tips

When you point your WinXP/W2K3 computer at the Microsoft Windows Update Web site
(same thing happens with a Windows Software Update Services, or WSUS, server). 
You try to download and install updates, and get an error:

0x800704DD and 0x80240020.

MS Knowledge Base article 910341
have lot of information can help, and it's a doozy involving the usual warnings about editing the
registry. Start by logging onto the computer as a local admin. Use
Runas.exe to run Internet Explorer as a local admin. Try Windows Update
again. If it works, then you need to fix the registry for non-admin users.
Open Regedit and find HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\
CurrentVersion\Winlogon\Notify\SensLogn. You need to verify several keys
and values:

Key                Type                  Value
Asynchronous       DWORD                 00000001
Disconnect         String                SensDisconnectEvent
DLLName            String                WlNotify.dll
Impersonate        DWORD                 00000001
Lock               String                SensLockEvent
Logoff             String                SensLogoffEvent
Logon              StringSensLogonEvent  
MaxWait            DWORD                 00000258
PostShell          String                SensPostShellEvent
Reconnect          String                SensReconnectEvent
Safe               DWORD                 00000001
Shutdown           String                SensShutdownEvent
StartScreenSaver   String                SensStartScreenSaverEvent
StartShell         String                SensStartShellEvent
Startup            String                SensStartupEvent
StopScreenSaver    String                SensStopScreenSaverEvent
Unlock             String                SensUnlockEvent
This is the sort of that makes you totally lose faith in the registry
as a place to store configuration information — how did this get
messed up on my machine? The workaround, by the way (should the above
not fix the problem) is to not use the Web site. Seriously. You're
supposed to just let Automatic Updates do the work, which is fine,
except that it won't download optional updates you may want. So,
let's hope the above registry changes fixes things for you.

Microsoft has relased LimitLogon v1.0.

LimitLogin v1.0

LimitLogin is an application that adds the ability to limit concurrent user logins in an Active Directory domain.

It can also keep track of all logins information in Active Directory domains.

LimitLogin capabilities include:

  • Limiting the number of logins per user from any machine in the domain, including Terminal Server sessions.


  • Displaying the logins information of any user in the domain according to a specific criterion (e.g. all the logged-on sessions to a specific client machine or Domain Controller, or all the machines a certain user is currently logged on to).


  • Easy management and configuration by integrating to the Active Directory MMC snap-ins.


  • Ability to delete and log off user session remotely straight from the Active Directory Users and Computers MMC snap-in.


  • Generating Login information reports in CSV (Excel) and XML formats.


LimitLogin grants System Administrators, Help Desk staff or any other IT-related personnel the ability to quickly query for any user logged on to the domain and view the machines they’re currently logged on to, while enabling the above list of features and management tasks to be performed on those user sessions.

LimitLogin Setup Components

LimitLogin set-up is combined of three different components: IIS (Web Service), Active Directory and Client.

The set-up should be done in this order since there are dependencies between the components.

LimitLogin is set-up through 3 different MSI installers:

LimitLoginIISSetup.msi, which installs the LimitLogin Web Service (WSLimitLogin)

LimitLoginADSetup.msi, that sets up the Active Directory changes needed for LimitLogin to work.

LimitLoginClientSetup.msi, which installs the client-side requirements for LimitLogin.


Enumerating Shares and their ACL’s

I recently find a good blog post from cavis which about enumerating the ACL of Windows Share folder, so i re-post in here:

In the Windows 2000 and Windows 2003 Resource Kits (and going all the way back to NT4.0) there is a tool called SRVCHECK.EXE. This is a simple command line tool that can enumerate what shares are on a local or remote machine and list the permissions on those shares. Since it is a command line tool, we can easily create a batch file that will list all the shares on all the file servers in the network……let’s do it!

I am going to work this from a Windows 2003 server but all the information is accurate going all the back back to NT4.

First, get the resource kit installed. The installation of the Res Kit tools does NOT require a reboot. However, the PATH= statement in the System Variables gets updated so you can run the tools from anywhere at the CMD line and that change DOES require a reboot to register. Otherwise you will get “path not found…” when trying to execute tools from the CMD line.


Now that we are installed, we have access to a virtual cornucopia of tools that can assist us with everyday administrative tasks. The SRVCHECK tool allows us to retrieve information about shares on a machine and what permissions are assigned to those shares. So if we drop to a command prompt now and run SRVCHECK we should get some info……..wrong. Unfortunately SRVCHECK *requires* you supply a machine name. It does not default to the local machine if there are no parameters supplied.


So even for the local machine shares you will need to supply a machine name in the syntax:

srvcheck \\computername


On my machine (lonestar) we find a number of shared folders. SYSVOL, NETLOGON, LONESTAR.LOG – because this is a Domain Controller……..Address and Resources$ – Because this is also an Exchange Server and finally…….Storage-Lonestar – Which is a public file repository on the network. We also see a list of accounts or groups as well as their permissions listed.

Now….this tool is only supposed to show “non-hidden” shares. Staring right at us is a hidden share – Resources$ – from Exchange. (hidden shares will have a trailing “$” character)

If we compare this to our Shared Folder properties from Computer Management we do see there are other hidden shares on the system that are NOT displayed by SRVCHECK. Most of these are the administrative shares


Okie…..back to the permissions. It should be noted that the SRVCHECK tool is NOT enumerating NTFS permissions – only the share permissions. You can change the NTFS permissions all you want but when you run the tool, you will only see the resulting share permissions.

So….two pictures up….where we see \\lonestar\Storage-Lonestar          Everyone            Full Control             this means Everyone that connects to the share over the network has Full Control over the folder and files in the share UNLESS there is an NTFS permission they have or obtain through group membership that limits them in some other way.

To demonstrate, I will change some permissions around…we will add a test group called Goobers with Share Permissions of Full Control and leave Everyone as Full Control. But we will set NTFS Permissions for Goobers to READ.



Now when we run the SRVCHECK tool….


We see that Goobers does have Full Control as a share permission even though they only have READ at the NTFS level.

Remember – Share permissions only apply when accessing the object over the network. NTFS permissions apply when accessing the machine locally AND over the network.

Okie… that we have shown we can pull the shares and permissions from any machine we name with SRVCHECK, how do we use it to generate a report of ALL the shares on our network? It does require some leg work since the tool can’t scan for shares. You MUST supply a machine name for SRVCHECK to search against. So you will need to collect the names of the machines on your network you wish to scan. For my test network, those machines are –

lonestar, godzilla, wallofvoodoo, vidtopia, and sleestak

We will need to create a batch file (shareperms.bat for my demo) that has the SRVCHECK \\computername parameters….


….save this to wherever you save your system utilities (we all have a folder we save tools in…..) and then run!


You will notice a failure on my setup because wallofvoodoo is offline. We obviously can’t pull information from a box that is offline so it errors out. If you have a similar situation on your network, you will see a pause while the batch file runs and attempts to locate the offline machine.

Now this is all great……but the output is to the screen only. You can pipe the output to a file though. This requires modifying our batch file just slightly. I am going to add the “>” character which is a near universal means of redirecting the screen output to a file you specify. Check the screen shot below….


Now when we run the batch file, the screen output is dumped to the files we specified after the pipe character. We end up with a report of each machine we specify in our batch file in a handy text file format.


If you open each of the resulting output files, the results are identical to what you would see on the screen.

Now the downside to this tool is there is no way to combine all of the machines queried to a single file. Nor is there an easy way to append the files over time. Each time you run the batch file it will over write the results. So if you decide to schedule these, you will need to add some logic to the batch file to modify the file name stored. I would suggest adding a date stamp for easy identification. You may wish to keep each machine queried in its own path as well especially if you have a LARGE network you are running this against.

I pinged a few internal aliases for some ways to do this with other methods of scripting as well. I have a couple of responses which I am going to evaluate and may post here at a later time if you want something a little fancier.