I searched, so hopefully this isn't already a posted question already.
Basically, when we have users connect to the network via VPN, even though the login script will run and map their network drives, their home share drive (in this case P:) does not reflect the network version and shows the "offline" version.
The problem is they don't see all their files, and of course don't know how to trigger synchronization. Of course ideally we would just turn it off and there would be no problem, but as most of you know, working in a corporate environment we're bound by the decisions of the guys in another department.
So, is there a way to trigger folder synchronization? OR is there a way to force Windows when mapping the drive to look to the network version? I tried the true switch on the mapnetworkdrive method of the WSHnetwork but no joy.
Found a simple solution, you can call "mobsync.exe /logon", closing thread.
Details from microsoft, their pages move around so this is just a search.
Related
This is probably a pretty easy question to answer for someone that is experienced with FS minifilters. I am trying to script the removal of a filter driver and device.
Some background... this driver is running on Windows 8/10 x64. The vendor that created the driver has not been helpful in fulfilling my request for a removal tool. Unfortunately their MSI uninstall is buggy and only works about half the time you run it... They want us to upgrade to their newest version that doesn't have the bug we are encountering during uninstallation. We aren't interested in continuing use of this software so a paid upgrade seems frivolous... Their only suggestion has been to reimage the computers without the software that includes the FS minifilter device... That's out of the questions because it is on 1000+ computers...
Basically, their official uninstaller does an API callback to one of their servers and verifies the machines eligibility to uninstall:
Does the MAC address of the primary network adapter exist in their
database?
Does the password you entered for uninstallation match
what is set in their database?
If you are eligible, it runs an MSI uninstallation and disables the FS filter, removes the driver file, service files, configuration, and restarts... The bug that is keeping us from doing a normal bulk removal (their way) is that the MSI freezes during the removal process (after checking eligibility) and requires us to restart a client computer up to 3 times to finish the uninstall.
I have been able to successfully remove the software and device/driver by externally mounting the Windows file system and manually removing the driver file under System32/Drivers and also removing all of the actual program files/services. I have not been able to do this booted onto the same partition where the minifilter is loaded. The minifilter driver that is running is protecting those program files, a registry key, and the actual .sys file under System32...
I've done some basic reverse engineering of their MSI... They are using custom actions to perform the removal... First step is the removal of the service, second step is the removal of the minifilter. Both actions are done via an executable that is packaged in the MSI... I've extracted that and attempted to use it by running the same commands that they do during the MSI... I haven't had any luck. The minifilter just doesn't want to die.
They have some other custom actions that are loaded via DLL. Initial investigation makes me think its all of their custom uninstall eligibility craziness.
It looks like their minifilter doesn't have an unload routine built in. Using FLTMC I get this error attempting to detach and/or unload:
0x801f0010 Do not detach the filter from the volume at this time.
0x801f0014 Do not detach the filter from the volume at this time.
Does anyone know of a good way to unload a minifilter that is throwing those errors?
Try to kick out FltMgr.sys of the kernel by:
Renaming %SystemRoot%\sytem32\drivers\FltMgr.sys
Or changing HKLM\SYSTEM\CurrentControlSet\Services\FltMgr\Type to 0x4 (Disabled)
Reboot
Minifilters can't work without Filter Manager.
If you are desperate enough, look into Windows PE, available as part of the Windows Assessment and Deployment Kit.
A Windows PE image can be remotely installed onto a machine's hard disk and configured to perform whatever task you need done and then automatically reboot back into the original operating system. Doing it this way gives you the same access as externally mounting the infected file system, but can be automated. I've used this approach in the past to automate offline maintenance tasks on several hundred machines (e.g., changing a registry setting that Symantec Endpoint Protection was "protecting") and while getting it working is fiddly, once it is working it works well.
My email address is in my profile, you're welcome to contact me if you decide on this approach and have questions about implementing it.
Alternatively, depending on your jurisdiction and circumstances, you might want to consider threatening the vendor with a lawsuit if they refuse to provide a proper solution. They broke your computers, it should be their job to fix it. From the sounds of it, they wouldn't even need to do any work, just let you have the upgraded version for a few weeks free of charge.
Our IT folks are telling us (the dev group) we shall not have ANY files stored on our local hard drives, including our TFS working folders. This is ridiculous for a variety of reasons but until I'm convinced it's a good idea, I'll play along and when no one is looking make a local working folder.
Does anyone does have their working folder on a network share? How well does it work? Each developer would have their own folder in the share but it would be on the network. My main concerns are performance and we would need to be connected at all times in order to work.
On a TFS point of view it's working without issue, but stay away from the Local Workspace of TFS/VS11.
I strongly feel for you on the compiling point of view, compiling a solution stored over the network is absolutely a disaster in term of performances.
You did not mention it but I assume your Network Share uses a Network Drive.
Btw, can I know why these guys don't want you to store files locally ?
While it's not something I would typically recommend, if that is the policy and you have to adhere to it, it might be worthwhile to consider simply having server-side development VM's that your devs RDP into. I've seen companies do this before, and the big downside is that if your not connected to the network you can't do anything.
There are some upsides too though. Being able to easily increase resources (RAM, disk space, CPU, etc) because of the virtualization infrastructure. If somebodies laptop dies they are not out of comission, just find a loaner machine and RDP into their VM and they're up and running. If somebody leaves, you have a copy of their entire working machine that you can give to their replacement. All machines can be easily backed up. Etc. Compiling, and working within VS in general should be much faster too than trying to work with a local Visual Studio reading/writing to a network drive.
I'm currently working on a migration from svn to mercurial. My needs are plain and simple, I need source control over an intranet in our company. I see examples everywhere for setupping remote repos over IIS. I just don't see the point when I can just make a share on a server.
Can I still setup authorizations and authentications on repos using NTFS permissions?
Am I missing something?
Thank you
Putting a repository on a file share works, but it's not the way recommended by the Mercurial team.
See the "shared disk" part of Publishing Repositories on the HG wiki:
generally restricted to intranets, not generally recommended due to general issues with network filesystem reliability
Be sure to check out Chris Becke's answer as well, because he points out another valid disadvantage (people with write access deleting stuff from the network share, be it intentionally or not).
If you are aware of (and can live with) these things, putting the repositories on the network share is without a doubt the easiest way to setup.
My personal experience is that it works perfectly as long as the Windows share is on a "real" Windows machine.
At work we're using a share on a real Windows server without problems, but at home I ran into issues with a NAS (which behaves like a Windows share but actually runs on Linux).
You can read more about my experiences here:
Can you 'push' to network share using Mercurial on 64bit Windows 7?
There are a number of reasons to prefer, well, anything at all to a writable file share.
In essence it comes down to, there is a limited amount of damage someone can do with the ability to do a push via a web-method.
A read/write share on the other hand is necessary to do a push, but also allows a user to delete an entire repo, history and all.
Without even invoking malicious intent, people (or rogue software agents) have been know to navigate to random network shares and accidentally drag a file to someplace it doesn't belong.
The best reason to lock your PC is not because your co-workers find it amusing to use an unlocked email account to send porn to HR, but because its amazing what a cleaning lady can do with a rag and a keyboard. Its also amazing what Music Library applications can find while scanning all shares in a workgroup, and carefully "move" and catalog to someones Library.
I'm working on a windows platform and want to be able to auto sync my files one way 'on change' to my virtual windows or linux web server - also need to be able to filter file types. i can connect to the remote machine via network drives.
i'm ideally looking for a free, easy to set up solution - a commercial product that does what I need is called ViceVersa but its a little overkill and costs :)
Thanks
Josh
I'd use rsync - simple, easy to setup, and provides the filters you need. Also very low on bandwidth after the first pass.
Here is a link explaining how to get it working in Windows
Whilst rsync doesn't allow 'on-change' auto-syncing, it is very fast when it scans a sync'ed directory (even very large ones), so you could schedule a frequent sync to overcome this.
Edit: You could combine it with a program like this, to trigger an rsync on folder contents change. Cheaper than viceversa
For other users, its worth mentioning lsyncd, it will auto sync on changes between two machines (by default deferring to rsync). Will only work on Linux though, but if thats not a problem it works great.
It also seems that Sparkleshare has finally released some working code (Dropbox clone). Havent tried it myself but does cross-platform synching and you can setup your own server.
I would like to programmatically add to Windows a name / IP association so that this name can be resolved locally. This does not have to be persisted between reboots.
The only way I now is to add an entry to the "hosts" file, but this feels hacky especially since I would like to automate this.
Is there any way to do this using a command-line tool or a Win32 API? Perhaps by addind an entry to Windows DNS cache or something similar?
Oh, and please state if this solution is Vista-compatible.
Regards.
Edit : Thanks, guy. Sadly, all of your answers indeed involve DNS or other servers. I was looking for a purely local solution which would work on a "standard" Windows installation. Such a thing does not seem to exist, though.
This page lists a bunch of scripts for doing various things with the DNS service, including adding a name to it. This seems to be part of the Windows Management Instrumentation system, which I'm afraid I don't know anything about.
EDIT: There is also this function, which says it can add records to the DNS. Not sure if that means that it actually modifies the DNS server's state, or if it talks about the local resolver. It also requires Windows 2000 Server or greater, so it might be too narrow.