Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Need help killing a bad shared file. 2

Status
Not open for further replies.

wishiknewmore

Technical User
Feb 27, 2002
39
US
I've found the root of some of my earlier problems with the server locking up to some extent, but I don't know why.

There is a shared Excel file on the server that is updated on a daily basis by one of the employees. There are very similar Excel files that also get updated with no problem. When this one particular file is saved, it locks everyone out of the shared folder. Additionally, with the exception of one or two workstations, I can't see any other workstations from my own. I can see all workstations from the server.

The solution so far has been to reboot the server after business hours. Unlike the other Excel files, when I try to view the properties on the suspect file, the screen locks up until I crash out of that window.

Does anyone know a way I can break the connection to this file to get the system running properly again without a reboot?

 
Also you can always right click on 'My Computer' (on the machine hosting the file) and go to manage and then expand 'Shared Folders' and expand 'Open Files' find the open file and right click and choose 'Close Open File' but that doesn't always work.
 
Thanks for the suggestions. Neither worked for me. The file is on the server itself in a folder that's shared to all.

I see nothing in task manager that's of any help either.

I installed the unlocker app, but no luck with any of the options offered.

 
In Windows Server 2008 to see if a file is locked you want to use Server Manager.

Once in Server Manager expand Roles -> File Services -> Share and Storage Management. Select the Share and Storage Management item in the navigation pane (first pane). In the middle pane you should see a tab labeled Shares and it should be highlighted. Below you should see all of your shares listed. When you find the share that contains the excel file in question highlight that share. In the third pane under the action menu you need to click on Manage Open Files. You should see the excel file listed. Select the file and click on Close All....

If the above steps don't work then I would tell you to stop rebooting the entire server. A less drastic step is to just stop the service. File and Print services fall under the Server Service.

Hope that helps,

Jason Beaudette
Technical Architect
 
Jbeaudette,

Thanks for the info. I'm learning as I go along. The suggestion you made didn't open to any files, only folders. Probably to be expected as most users have shut down and gone home now. The ones left are pretty much locked out of any shares due to this problem.

I'm looking under the services in Server Manager > Active Directory Domain Services > System Services. I'm not sure exactly which service to shut down. To confuse the issue even more, I'm not 100% sure I even have the shares setup right.

Basically, I have this setup like the domain was under our old Windows NT-4 Server. There is a "D" partition on the drive with a few folders and subfolders where I have set the share and security options. That's about it.
 
You're welcome, wishiknewmore.

To stop file sharing you want to open Server Manager -> Configuration -> Services. Once you select Services then look for Server in the name column. That is the service you want to stop and restart.

As for you concern over an improper share configuration I would say that is most likely not the issue. You setup while simple should do the job.

 
Thanks again, jbeaudette. I was out of the office on Thursday, and there seemed to be no problem. This morning (Monday) it reared it's ugly head again with a different file. I trued stopping the services as indicated in your last post, but it wouldn't shut down. I had to resort to the reboot method again.

I think I may have found the problem, but don't know what to do about it for sure. Originally, this server was running Windows NT with our internet router acting as the DHCP server. We had no problems. Now, the router is still issuing IP addresses, but Server 2008 is also running the DHCP Server role. I have a feeling there may be a conflict in this area and only one should be running. My guess is, the server should be issuing the IP addresses.

If this is correct, do I need to do anything besides turn off the service on the router? I can furnish example IP address setup if it helps.

 
Duplicate DHCP is only a problem if the scopes (IP Ranges) are duplicated in both locations. Which they most likely are if you are having these conflicts. I would make the Windows server the one issuing the IP addresses.

Yes, stopping the configuration on the router should be enough. However, you want to make sure your clients are getting addresses from the server. You have a couple of choices and the best process depends on the number of DHCP clients you have in your environment.

If you have only a few clients, then you can simply turn off the DHCP service on the router. Then visit each client and do an IPCONFIG /Release followed by an IPCONFIG /Renew. You should see in the IPCONFIG /all report that the DHCP Server IP matches the IP of your Windows Server.

If you have a lot of clients, then you need to phase out the router as a DHCP source. On the router set the DHCP lease time to a very short period of time. I might use an hour as an example. Wait for a time equal to the old lease time (often 8 days) and then you can stop the DHCP service on the router. This will give all the DHCP clients that have a lease with the router a chance to acquire the shortened lease period. Once you stop the DHCP service on the router those clients will know in less then an hour they need to find a new address. They will end up getting that address from the Windows Server.


Hope that makes sense...
 
Exactly the procedures I tried this morning. I have about 30 clients to work with. I'd taken exactly those same steps prior to the workforce arriving this morning on 13 clients when I found they couldn't reach the internet. I reversed my actions at that point to go back to the drawing board. I have the ISP's IP addresses in the DNS addresses on each client, but that didn't work.

I'm still having occasional lockups during various shared file accesses. I've checked the sharing and security settings and they are correct. It's a different file nearly each time that locks things up. The only way out is a reboot of the server.

At this point, I have the router issuing IPs again and unauthorived DHCP on the server as well as stopped the DHCP service. So far, no problems with that setting, but the day isn't over and I'm sure that's not the way it should be done.

 
WishIKnewMore,

Your current solution should work. Now that there is only one DHCP server issuing addresses in that range.

If you want it to run on Windows instead of the router I have included some info below.


First, a couple of questions....

Are you running Active Directory?
Are you clients joined to the domain?
Is DNS integrated into Active Directory?
Are you clients set to aquire both and address and dns settings from DHCP?

I would bet that the reason you ran into problems is due to DHCP scope options. These options tell the DHCP clients details about your enviroment. Common scope options include: Domain Name, DNS server address, IP Gateway, and WINS address (if you have NT/9X clients).

You scope options should be set with your internal DNS address and an IP Gateway.

You also need to make sure your DNS server has a forwarder to your ISPs DNS server address. That means any address that your internal DNS cannot resolve will be sent to the ISP DNS.

When dealing with a 30 clients and a handful of servers, I find it easier to have AD, DNS, and DHCP on a single server. While it will function fine on the router, if they are all on the same box when one service is found the others are found.

My two cents....

 
So far, so good with the current setup. At least the villagers have put down the torches and quit ratteling chains.

Yes to AD.
Yes, all clients are on the domain.
DNS integrated into AD: How would I check that?
Clients are set to aquire addresses via DHCP, but DNS settings are "hardwired".

Not sure about the "forwarder" in DNS. Assuming I'm looking in the right place it shows "same as host" with the server IP listed there.

I have two servers in the domain. One is the domain server and the other is a SQL server which is humming right along.

A thought: Would it make sense to set the server DHCP scope to a very narrow range and set one testbed computer to receive it's IPs from the server? In this way, I'd have at least one workstation I could work with to iron out the problems.

Time is a big factor in what I can do. I come in early each day, but there are always early birds that need on the net and in the evenings the owners are her and logged in until all hours.
 
Another day and the problems continue, but possibly another piece of the puzzel.

Yesterday, I stopped the DHCP server service so the router was the only thing trying to issue IP addresses.

Part way through the day, the same problem occured, the shared files all locked up when someone tried to save a file. Again, the shares and security permissions are correct. I rebooted and again set the DHCP server service to "stopped" - "manual". I probably should have just disabled it, but that's an afterthought.

Later in the day, the service had not restarted but an Excel file again locked the system when it was saved to a shared folder.

It now appears that the DHCP has nothing to do with the problem. I brought the suspect Excel file onto my workstation and it opened and saved with no problem. I fail to see why it should cause a problem when in a shared file, but it does.

 
I've gotten away from my orginal problem, but some of the suggestions have brought up another problem or question, so I'll take a chance and continue rather than start a new thread.

Here's the current setup and problem. My router and domain server are both DHCP servers. I want to migrate to the domain server being the only DHCP server, but want to do it slowly to make sure it's working right.

At the moment, all but one client are receiving their IPs from the router and all is working well in that area.

I've set the DHCP server on the domain server to a tight scope of one ip address outside the scope of the router's scope.

I have one testbed client receiving it's IP adress from the domain server. that is working too, except I cannot get to the internet on the testbed client. The domain server is not passing the default gateway IP. When I run "ipconfig /all" on the client, the default gateway shows a blank even though it's listed on server.

There may be a problem (just guessing) with the alignment of the IP addresses. Here is what I have:
router (default gateway) = 192.168.1.1
Domain server = 192.168.1.2
Domain server DHCP scope = 192.168.1.227-1.9.168.1.227
Testbed client is picking up the 192.168.1.227 as it's IP like it should.

Is there possibly a problem with the IP address of the router being set lower than that of the Domain server?

 
Don't know what other files types you are sharing, but I had a nasty situation caused by network access of old database files which brought up the issue of having oplocks enabled. In the past on the older OSes, oplocks enable basically affected just the databases, very easy to diagnose. With server 2008 the entire network was affected with oplocks enabled... particularly all the servers, a mix of server 2000s and 2008s. You might want to diasable SMB signing.


........................................
Chernobyl disaster..a must see pictorial
 
Technome,

That sounds interesting. If I disable SMB signing, will I still be able to share folders and files? I found a little about it in the help file, but I'm not all that clear.

How do I go about disabling SMB? Is it global setting, or per file?

 
Technome,

Disabling SMB signing did the trick. It's been a day and a half since I disabled it in group policies and no lockups since.

Thanks for the tip. Much appreciated.


R.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top