BootManager
Members-
Posts
21 -
Joined
-
Last visited
Reputation
5 NeutralAbout BootManager

Personal Information
-
Occupation
Technical Manager
-
Location
London
-
By the way, I do have reserved DHCP entries although some of these dont actually get used since the servers have fixed/manual IPs. It doesnt do any harm to list the items anyway since it puts everything in one place and I know whats free and what isnt.
-
I think the main thing was that it just looked in a mess when comparing it to DNS at a different school, or I should say that perhaps it just looked 'different'. When I rebuilt DNS I had the forward and reverse zones, my cached lookups and my events folders, nice and neat. One the old DNS I also had things like _msdcs on the same level and possible some other entries. I guess the important thing was that the server had been through an upgrade path from Win2K so some old functionality was being catered for, possible to the detriment of a happy win-mac environment. So when I did the rebuild I took the opportunity to switch to Win 2003 functionality ONLY. Another important issue is probably to not manually add records to DNS while logged in as another user, I think the old records got added by our apple contractor using remote desktop, (no idea what he would have logged in as), and I believe windows system then treats those records totally hands-off, or something [i can't remember exactly what I read but it was in a windows online doc], ....erm basically I registered my servers, including macs, by instructing the servers to register themselves in DNS instead of manually adding records to DNS directly. Anyway, I'm still happy to say the network is continuing to behave itself now.
-
Hi All, finally got back to posting a reply and the good news is that my apple-no-login-shake problem now seems to have gone away, *joy* , so the rebuild of the DNS did the trick, I can use the windows side for weeks, then switch to the mac side for a lesson (no shake off), then back to windows. To think of all the time I wasted rejoining the domain on each and every mac for each and every time I needed to use it. Well now its fixed and nobody, not even the apple experts, ever suggested that the problem is all down to DNS. Thank you.
-
An update.... well I found out that some of my dual boot macs that got reconfigured now wont log onto windows, it says the domain is not available, fixed this by logging into a local windows admin account, deleting all the local profiles for domain accounts (they all were marked as unknown account anyway), then coming off the domain and finally back on domain. It seems that although the dual boot win side was originally happy, problems occurred after the dual boot OS X side was taken off the domain (and re-added). Generally it doesnt bode well. Oh and yet another mac has gone faulty, is there anything more unreliable than an apple-built computer?
-
(continued).... what I found after doing some reading was that our DNS was probably in a bit of a mess from upgrading the server from win 2000 to win 2003 some years back and also from having various experts come in and allowing them to hack about, particularly when they manually add records to windows DNS from their client machines (eg a mac server). The DHCP settings were also messed about with, probably by external 'experts' like half-setting-up range policies when in fact the top level server policy had all the relevant settings already set up. But I also found that our Active Directory was 'old' and needed to upgrade to Win 2003 (a single mouse click operation). The articles on DNS are fairly straightforward though I found that some things didnt apply to our setup here and there were a couple of minor panics when I thought I'd done some damage, but as it turned out everything was really quite easy, you just have to plan it out. I'm not going to go into massive detail, most of the actions are performed from menu options or right mouse clicks, you do need to feel your way around the DNS structure but most actions are performed on the 'server' container and not the zones (which were getting deleted). I think that the steps that I took [on each DC server] were to: 1) break the replication across the servers by setting DNS to standard primary on each server and make sure there is no cross referencing of servers. 2) from the dos prompt use command "ipconfig /flushdns" to flush cache, then after a couple of minutes to go into DNS console and just delete all the A and PTR records for each zone, then note down all the C records (because you will need to recreate them), before deleting each zone in the forward and reverse containers (I also found/deleted a top level _msdcs_ zone that I think was supposed to be a child of a named zone - can these things be moved?!?) 3) clear out the DNS events log, then come out of DNS console. another flush of the dns from the dos prompt, and then stop the DNS service (net stop dns). 4) The microsoft documentation talks about deleting zones from within Active Directory but I couldnt see where any old records were kept, however I did find that there were some old files in the folder c:\windows\system32\dns, (these have the extension .dns) so I moved the ones that obviously belonged to us out of the way to a new folder [ I left behind cache.dns and dns.log and the folders Samples and Backup ]. 5) Network Connection Settings. I had some conflicting info on this change but what I opted for was for each network connection on our nominated DNS servers to make sure that if its a static IP then the network settings has preferred DNS pointing to itself, ie a server with replicated DNS doesnt point to the primary DNS server instead, the alternate DNS was set to point to the internet service providers DNS. In case you are interested conflicting arguement was pretty much the exact opposite ie to point to the primary DNS and the alternate DNS to point to a secondary internal DNS - but I'll monitor what happens as I can always change these settings at a later date. 6) configure DHCP service on the machine where it resides. I didnt have to do much to ours but I changed a couple of settings out of interest, on the general tab "enable DHCP audit logging" ticked, on the advanced tab "conflict detection attempts" set to 1, and on the DNS tab everything ticked (I selected "always dynamically update DNS A and PTR records" on the option) . Although I didnt delete any records, you may want to tidy things up if you know some leases have expired, you can select the Reconcile action to give a little peace of mind afterwards. One thing which I did do was delete the scope options that someone had half-heartedly set up on the main scope - on our DHCP server these options are correctly set up in the global options and therefore do not need any overriding (or messing up). 7) when all servers are stripped of dns operations then reboot each server, except for the mac servers - which got taken off the windows AD domain and then shut down. 8) The DC servers get booted first, the other servers get booted after you set up DNS. 9) IMPORTANT NOTE: On the Primary DC in Active Directory a right click >properties, on the domain name revealed that our Domain Functional Level was set to Windows 2000, but a simple mouse click allowed this to be upgraded to Windows 2003 (an upgrade that cannot be reversed). I feel this is an important issue because it shows that the AD is being made overly complicated by trying to retain compatibility with Windows 2000 or whatever, but since we no longer have Windows 2000 servers I decided to ditch the functionality and upgrade. 10) On the primary DC I setup DNS pretty much using default settings of the DNS wizard (from "Configure Your Server"), there is an option to replicate to all the DCs and you should do that. Give it a few minutes to replicate across your servers. You can also run some tests to check DNS is behaving correctly. 11) On each server with a static IP you should then go to the dos prompt and issue the command "Ipconfig /registerdns", note on the mac servers there isnt really a command to do this but on the macs you can configure IPv4 with the option "using DHCP with manual address" which will register the static IP address in DNS. 12) You can use directory utility to get your mac servers rejoined onto AD; note I did put a tweak on my mac servers (dsconfigad -passinterval 0) as per some earlier recommendation. 13) remember to manually enter any C (alias) records in your DNS, things like which server hosts your website are fairly important. Hopefully thats everything to configure the servers. Thats all I can remember. I wanted a situation where the DNS entries are controlled by windows and tied in with active directory. If you read the microsoft notes it talks about records remaining in DNS if they were manually inserted, ie the owner of the record is not the system, something that I would consider bad news if you want a to go for dynamic updates, and could potentially lead to conflict/duplicates on addresses I think. I'm sure that there is going to be a whole lot of people out there who are going to criticise my actions, telling me that I cant possible be right, well OK you have your opinions, but solutions like "have you synchronised time" or putting techie tweaks on mac variables are not exactly 'out of the box' and one fact that I think you should chew over before you rush ahead anyway is to consider this: Some sites that I know of do not have any problems with mac integration. The people who set those sites up didnt go off performing techie tweaks, they just had a bog-standard windows network, freshly built, which they then connected their brand new apple macs to using Directly Utility. AND IT WORKED AND CONTINUES TO WORK. So all I'm trying to do here is to take away some of the complexity which potentially has been caused through upgrading, upgrading is a nice convenient thing but sometimes its messy. So I've rebuilt my DNS and made some slight changes to DHCP and Active Directory, as far as I'm concerned I'm trying to simplify the network, thats all. Finishing Off Well this is the moment of truth, which unfortunately I wont find out if its worked until probably a few weeks time. First step, just boot all the windows machines and logon to an AD account, you can probably guess that nothing went wrong with this step. (dual boot macs were booted onto the windows side before even thinking about booting onto the OS X side). On the macs, (dual boot macs were booted onto the windows side before even thinking about booting onto the OS X side), I booted into the local admin account, then did the tedious setup: 1) followed the procedure to get the macs off the AD and OD, deleting directory utility plists afterwards. 2) check the computer name is correct, then check/correct the name of each network connection, the TCP/IP tab should state "Configure IPv4 using DHCP" 3) check for software updates, then reboot. Back into mac (on dual boot machines) 4) rejoin AD and OD, this time I joined OD first of all. Shut down. 5) hope and pray that your mac woes have gone away have I forgotten something - well probably - but do your research. reconfiguring your server can be a bit scary but some times its got to be done.
-
Regarding my DNS rebuild. I am writing these notes down now so that I dont forget what I did when I post an update on how my network is behaving (probably in a few weeks time). My feeling is that our windows network was fine for PC clients but macs, being extremely fussy, didnt like it. I rather suspect the apple have just done some minimal testing as far as integrating into windows environments is concerned and therefor if your network isnt 'just so' then your macs are going to go into a huff, ......did I mention about the hassle with using macs on our expensive and sophisticated network environment - the upshot was that we had to 'dumb-down' our switches in order to accommodate the picky macs with network card drivers that dont conform to internationally recognised networking standards [and Apple think its not their problem]. Anyway this is what I've done to our servers and I am still monitoring the situation, so dont take it as gospel.... Most of the client computers had been switched off over easter so the DNS records would have mostly been stale - the DNS was going to be flushed and rebuilt so it was to our advantage too. First step make sure all the servers (windows and OS X) are updated with patches, and BACKUP system state. Second step, refresh my brain on how to configure DNS & DHCP, I'm a great believer on setting things up with the instructions in front of me, then hopefully I wont need to look at for at least a few years. Third step clear down DNS and de-integrate it from active directory. Then stop the service and delete all traces of DNS in AD or text file. Fourth, check DHCP, reconfigure if neccessary Fifth, configure the servers and get them all talking and behaving nicely with one another. Next, rebuild DNS and replicate across servers, check DNS contains correct records and register any machines with static IPs. Next get the windows client PCs back onto the network, well logon to an AD account cos you just know they are gonna work Finally reconfigure each mac client (our machines are dual boot), this is the tedious bit involving coming off the domain, clearing down plists, renaming, rebooting, rejoining domains etc, hoping that things get finally sorted. some reading (do read them): How to clear bad information in Active Directory-integrated DNS How to reinstall a dynamic DNS Active Directory-integrated zone How to configure DNS dynamic updates in Windows Server 2003 How To Install and Configure a DHCP Server in a Workgroup in Windows Server 2003 there are other articles, you can take days to read, but I'd decided that I was going to rebuild DNS so they were irrelevant to me. oh I'm too long on my text, read my next post....
-
another (old) thread on AD binding problems... Snow Leopard AD Integration woes today I rebuilt my Windows DNS and also played around with some DHCP settings. Also in Active directory I found that our domain it was flagged/running as "Windows 2000 Mixed" so I upgraded to "Windows 2003" (a simple click of a button - but one where there is no going back). Obviously quite a few changes and I'm currently monitoring the situation. I'll let you know what the outcome was in due course.
-
another (old) thread on AD binding problems... http://www.edugeek.net/forums/mac/43879-snow-leopard-ad-integration-woes.html today I rebuilt my Windows DNS and also played around with some DHCP settings. Also in Active directory I found that our domain it was flagged/running as "Windows 2000 Mixed" so I upgraded to "Windows 2003" (a simple click of a button - but one where there is no going back). Obviously quite a few changes and I'm currently monitoring the situation. I'll let you know what the outcome was in due course.
-
try this thread, no solutions yet... http://www.edugeek.net/forums/mac/51069-mac-will-not-log.html
-
just been reading this thread which has expands on my dns hunch... http://www.edugeek.net/forums/windows-server-2000-2003/50877-dns-reverse-lookup-server-2003-a.html
-
until you have experienced this problem for real then you cannot even begin to guess what the cause is. Currently I'm looking at rebuilding DNS, over easter when nobody is using the systems. its not a trivial problem, believe me there is no easy fix relating to time-sync, or locked-out accounts. you can logon as a local administrator and inspect everything on the mac client, everything looks fine, green lights on directory utility entries, time-synced ok. the only thing that I notice that is wrong is that the mac client may have somehow, strangely, inherited a name that it was never originally given. you cannot change the name unless you unbind from the AD & OD and even then the name change will only be affected after a reboot. there are no malicious people going around in the middle of the night hacking the computers or anything that would give a simple explaination. One day you can log on fine the next day you get the shake off. Do note that my computers are dual boot macs, that means that the NIC on the network card will obviously be the same if I choose to boot mac or boot windows, but the 'machine name' needs to be different for mac and for windows otherwise the AD entry for that particular computer may be right royally messed up. Our Domain was created many years ago and the operating system has been upgraded from win 2k server to win 2003 server. I can visit a neighbouring school which has a similar mac set up to ours except their win 2003 server was a fresh build a in recent years. Comparing our DNS setup to that schools reveals some wild differences, and since that school isnt experiencing the problems we are experiencing then I'm inclined to think thats where the issue lies. Also I have to think about what services the mac client may use, there really isnt many services that store info relating to machine name and ip address. going back to the weird computer-name-change thing, this was something I stumbled across completely by chance, after all you dont expect it to happen so you diont look in that area. Anyone that is experiencing these mac refusal to logon problems please do click the info text found underneath where it says "MAC OS X" on the logon box and note down what it says for the computer name, IP address, etc. you can then investigate your DNS, or AD and follow the trail DNS forward lookup to reverse lookup and note if there are any duplicate entries particularly on the reverse lookup. And please do report back here, I would be interested to know.
-
we've had apple experts in to fix our problem on several occasions, the result is just the same - once the mac is bound to active directory they think the problem is fixed. The problem THE REAL PROBLEM is that for some unpredictable reason a mac will 'forget' that its bound and there is absolutely nothing that you can do about it until you unbind/rebind again, this typically happens a few days or weeks after the apple experts have been and gone. The apple experts that we've had tend to think that nothing can possibly be wrong cause macs are 'so superior' that nothing could possible be at fault. But I've been on the Apple Certified training courses and the off-the-cuff advice we got was dont rely on any bundled apple service (except the web service), apple may upply pretty-looking software but business critical software it isnt. So though I'm not saying this particular problem is all apple's fault, I think its probably DNS related, dont be suprised if it does turn out to be apple. The time thing is again another red herring, yes if the time is out of sync then it will cause problems, but here all of our computers are synced internally to the main server and DHCP provides the correct parameters, everything looks OK on that front. There was an issue regarding daylight saving on the windows side of things but a boot camp patch fixed that problem some while back.
-
Macs and Ubuntu randomly loosing trust with Active Directory
BootManager replied to samba_man's topic in Mac
the time-out-of-sync thing will cause problems but lets assume that everyone who manages a network keeps their computers in sync. It was a known problem to do with BST but Apple patched that soon after boot camp was released, years ago. check the other posts on this topic, its a big issue thats been discussed before, no fix yet tho.- 9 replies
-
- active directory
- mac authentication
-
(and 1 more)
Tagged with:
-
well, I would bet its not sorted, this is an ongoing problem for many people, the 'fix' might last a few days or weeks. I've just put a whole load of stuff about this problem on another post.
-
sorry I forgot. Also on DNS subject, it would appear that the bad Apple mac client uses its last-used IP address to query a reverse lookup on DNS to find out what its computer name is ??!??? yeah it sounds crazy but follow the DNS trail, you will probably find that the only connection between the bad computer name that the bad mac client has got can only be directly linked via DNS using the reverse lookup, why this happens I dont know. the problem is that once the IP address is renewed by DHCP you will have to wait for the lease to expire before a issues re-occur. Its a tedious problem and not one to easily track down. Oh and by the way another myth to solving the problem is configure DHCP so that leases never expire or expire within a day. Both bits of advice seem to be clutching at straws, I tried both configurations, didnt help either way.
