Jump to content


 


Register a free account to unlock additional features at BleepingComputer.com
Welcome to BleepingComputer, a free community where people like yourself come together to discuss and learn how to use their computers. Using the site is easy and fun. As a guest, you can browse and view the various discussions in the forums, but can not create a new topic or reply to an existing one unless you are logged in. Other benefits of registering an account are subscribing to topics and forums, creating a blog, and having no ads shown anywhere on the site.


Click here to Register a free account now! or read our Welcome Guide to learn how to use this site.

Photo

Workstations suddenly do not have permission to Windows 2008 Server shares


  • Please log in to reply
12 replies to this topic

#1 Toten0Maske

Toten0Maske

  • Members
  • 14 posts
  • OFFLINE
  •  
  • Local time:12:34 PM

Posted 23 December 2014 - 11:06 AM

This is a followup technically to my previous post which can be found here.  Making this new post simply because it seems more like a 'new issue' than the previous issue in that thread.  But having said that I believe it is overall a DNS issue, just need help diagnosing and correcting the issue.   Original computer that I believed I fix is now unable to gain access to the shares on the server by going to the \\servername.  Two other computers have developed this same issue in addition to.  Now if a user logs in as the Domain Controller admin account onto the workstation the issue does not occur, they have access to the server and the files, but once they switch over to the User on the workstation they do not have permission to access the location.  I will be heading out there this afternoon to check up on the possibility of this being a DNS issue (if I can access the server via its IP address instead of the name, I am sure it is something to do with the DNS).  

 

The funny thing is the computers were behaving perfectly for three days, and only yesterday did they suddenly start having these issues.  Question is do I concentrate on repairing the workstations DNS or should I investigate the Domain Controller to see if the DNS issue is originating there? And what should I do to proceed?

 



BC AdBot (Login to Remove)

 


#2 gavinseabrook

gavinseabrook

  • Members
  • 773 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:El Paso
  • Local time:10:34 AM

Posted 23 December 2014 - 11:47 AM

Sounds like DNS issue to me. Make sure that a reverse lookup zone is setup and the Server has a Pointer (PTR) record pointing to the IP. Also make sure the server is using the ISP DNS in its forwarders (Right click server root on left panel and select properties, then forwarder tab). Also make sure that the router is setup with static DNS servers, first DNS should be the server and the other two should be your ISP DNS unless you want the server to manage internet connections (IE: using the forwarders to control the flow of internet). When on the user workstations, open a command prompt and run an NSLOOKUP to make sure your server is pulling the FQDN of the server (IE: Server.mydomain.local). 


Gavin Seabrook

 


#3 Toten0Maske

Toten0Maske
  • Topic Starter

  • Members
  • 14 posts
  • OFFLINE
  •  
  • Local time:12:34 PM

Posted 23 December 2014 - 02:34 PM

Seems that there are no Forwarders listed on the tab. But the forward zones and reverse lookup zones seem to be configured

#4 gavinseabrook

gavinseabrook

  • Members
  • 773 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:El Paso
  • Local time:10:34 AM

Posted 24 December 2014 - 12:41 AM

You will need to add the ISP forwarders on there and make sure your routers is giving the main domain controller/DNS server as the primary DNS address. 


Gavin Seabrook

 


#5 Toten0Maske

Toten0Maske
  • Topic Starter

  • Members
  • 14 posts
  • OFFLINE
  •  
  • Local time:12:34 PM

Posted 24 December 2014 - 04:08 AM

Sorry about the limited post there - so in the forwarders tab I will put the Comcast DNS servers and make sure the router has for DNS the ip of the server (ex 192,168.10.91) followed by comcasts DNS server as secondary. The fact these two issues are present suggests that this issue originated once the server switched over from DSL to Comcast service with the original tech not making these changes I believe. Will apply these changes once the holiday is over and after business hours to test out. Will follow up to this post once completed.

#6 gavinseabrook

gavinseabrook

  • Members
  • 773 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:El Paso
  • Local time:10:34 AM

Posted 24 December 2014 - 11:58 AM

Sounds good. Will await your response.


Gavin Seabrook

 


#7 Toten0Maske

Toten0Maske
  • Topic Starter

  • Members
  • 14 posts
  • OFFLINE
  •  
  • Local time:12:34 PM

Posted 27 December 2014 - 12:29 PM

As promised, a followup.  Well had a slight snag with my plan of configuring the router - since this is a Comcast Business Gateway, and the small business is not paying for static IPs of any sort, trying to manually change the DNS settings in the LAN were ignored keeping the 75.75.75.75 etc as DNS.  But I did add the forwarders anyway to the server, and went a bit old school and simply added the server IP as Primary DNS and the Comcast DNS as Secondary for the computers experiencing the issue in the adapter settings for their network cards.  This has solved the issue today.  Hopefully I will be filled in as the week progresses if this slapdash fix corrects their issue overall.



#8 Wand3r3r

Wand3r3r

  • Members
  • 2,027 posts
  • OFFLINE
  •  
  • Local time:10:34 AM

Posted 29 December 2014 - 03:05 PM

Your AD server should be doing the dhcp serving for the network not the router.  Not only do the workstations get the correct ip info via dhcp but you can also configure the dhcp server to automatically update the dns server host records.



#9 Toten0Maske

Toten0Maske
  • Topic Starter

  • Members
  • 14 posts
  • OFFLINE
  •  
  • Local time:12:34 PM

Posted 30 December 2014 - 09:19 AM

Your AD server should be doing the dhcp serving for the network not the router.  Not only do the workstations get the correct ip info via dhcp but you can also configure the dhcp server to automatically update the dns server host records.

That's the thing, since I was brought into this situation - due to the previous Tech just randomly stringing the client  along and then apparently dropping them - I have been trying to ascertain the issues without taking the network completely offline since the office itself is constantly busy with patients.  Finding a permanent fix for an issue that should not be happening as the way the server and the workstations are set up is the the main goal at this point.  Each time I am brought in I have to work out what was previously done.  Apparently the Tech before had setup the workstations to have their IP addresses Static Per Workstation then out of the blue (according to the client) he switched it to auto after a certain period of time, once the client moved off DSL as their service provider to Comcast (and supposedly after one Microsoft Update causing major issues which there is no record of in any previous worklogs by the previous Tech - who really did not leave any detailed worklogs just simple "fixed network issue" with invoiced charges) is when the workstations started to have these DNS issues.  So overall, at this moment I am trying to figure out what is causing these issues - especially since the Domain Controller seems to be properly configured with Active Directory finally in order since the original Tech did not properly add one Computer account that was having the main issues to the Active Directory (it being the examining room workstation - one of their critical computers that needed to be up during the day).  Which took me at most 15 min to add and get running - even after the original Tech was claiming it was joining a nonexistant network that he simply tried fixing by renaming the network connection.

 

To be truthful, the situation I find myself in is due to the fact the Tech in question would randomly come in 'to fix a problem' and spend months letting the problem fester - now that he has disappeared once again, its something I have been pulled into.  Frustrating mainly because I had no part in setting up this network and have to work backward with the limited time given by the client throughout the day to quickly patch the workstations to a working state.  

Currently the three computers that have been having issues - by setting them to use the DNS settings I mentioned above, has resolved the issue of not able to \\servername to shares but \\ip.of.server (\\192.168.10.91 for example) to shares, but to me it is a temporary fix that needs to be permanently rectified other than as it has been done so far.  

My best guess is the situation trailed off to this point after Comcast was introduced as the ISP, mainly going by what the client noticed happening to their network shortly after.  I appreciate your feedback, just this situation for the client and myself is getting a bit frustrating. 


Edited by Toten0Maske, 30 December 2014 - 09:28 AM.


#10 gavinseabrook

gavinseabrook

  • Members
  • 773 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:El Paso
  • Local time:10:34 AM

Posted 06 January 2015 - 05:54 AM

Well I am glad that this has acted as a temporary band-aid to a bigger issue. I have too experienced coming into a new medical office where the previous technician did the weirdest setup I have ever seen. I think my worst one was running into an office where the server was broadcasting their data to the internet due to bad configuration of the domain and DNS. Any request to the server would look at the internet instead of the local network for the server, which obviously it was never going to find it. Logins to the domain would take about 15 minutes!


Gavin Seabrook

 


#11 Toten0Maske

Toten0Maske
  • Topic Starter

  • Members
  • 14 posts
  • OFFLINE
  •  
  • Local time:12:34 PM

Posted 08 January 2015 - 07:10 AM

Well this Saturday I have been called in to check out the computer systems again.  The issue of computers not able to see the server shares etc is actually no longer an issue since the 'bandaid fix'.  Now the client says the systems seem to bog down during the day - as in the workstations take longer to communicate with the server as the day progresses. The client is under the impression that it is because of their Server storage space is rather large and it needs to be trimmed down a bit.  I am not convinced that is the issue of course - but I can easily remove some extra logs etc to clear up some storage space.  Of course not seeing this sluggish behavior first hand I need to figure out if its actual communication between the workstations and the server that is the issue or something on the individual computers causing the sluggish behavior.  The Client is using Carbonite as backup for their Server, and technically if that is processing files that could slow down general network activity, but again this could be an offshoot of the overall issue of how the Server is setup.  In addition to this issue they want elevated permissions on a diagnostic machine which should be easy enough to perform and their database software needs a permanent fix applied to its permissions on the server side since they are experiencing a known bug.  Overall things seem to be working though the sluggish behavior of the computers in general concerns me. 



#12 gavinseabrook

gavinseabrook

  • Members
  • 773 posts
  • OFFLINE
  •  
  • Gender:Male
  • Location:El Paso
  • Local time:10:34 AM

Posted 14 January 2015 - 08:56 PM

Offsite backup solutions are horrible unless you have the proper bandwidth for them and depending on how much you are storing. If you have TONS of space, good for you, but it wont affect the speed. Now if you have TONS of space that is being USED and you have carbonite trying to back it up and many users attempting to access files, write to databases etc. then yes, you will have a problem. What are the specs on this server?


Gavin Seabrook

 


#13 Toten0Maske

Toten0Maske
  • Topic Starter

  • Members
  • 14 posts
  • OFFLINE
  •  
  • Local time:12:34 PM

Posted 15 January 2015 - 08:10 PM

I agree about offsite backups, the original tech recommended cloud based backups and I have suggested otherwise - especially since network traffic is key for this small office day to day business.  But checking the settings and the records carbonite has successfully backed up the system in the off hours of the workday.   Another issue was the fact that this server has no security software, which is being rectified.  I removed old log files as well as temp files from the server freeing up 50gb of space, I was going to run WSUS cleanup wizard but noticed how the database had not been cleaned since the date of the server's setup, and just knew the process would take more than a day to clear up, if not days.  I suggested we may have to uninstall WSUS and reinstall it to get a fresh start to get it to be managable on a regular basis, but removing the 50gbs of the main drive was enough for the client.   Now onto the slow traffic being experienced on the workstations during the day.  Initially, for testing purposes we had all the workstations turned on and logged into the software suite that the office depends on.  First half hour the workload was snappy, then suddenly the front desk communication started slugging and then completely reset the connection to the software that depends on a database on the server.  It was to the point that I needed a friend of mine to come in to help me work with the small office computers while we bounced off ideas of what could be causing the issue.  Since normal traffic didn't seem to be lost during the day, and the issue seemed to be just with the software package they used that depends on the database on the server we started working down a quick list of things that were the same on every computer and what features were enabled.  One thing that seemed odd to both of us was the fact IPv6 was enabled on the workstations, something I personally don't enable on what generally is a small office environment that does not deal with internet traffic business, so we turned IPv6 off on all workstations. After an hour of testing the systems didn't lose connection to the server while running the software that the company uses for business, to be safe we restarted all the systems and made sure that the issue did not reappear.  Customer seemed satisfied, even though to me I have this nagging feeling it couldn't be 'just that.'  I have been checking in with the client via text during the week and they have not had any more issues with the Server and Workstations since this last followup.  






0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users