RE: [ActiveDir] AD Restore Problem
However, as we have discussed her MANY, MANY times - it might not be SUPPORTED. That simply means that PSS is only going to give best effort. They are NOT going to tell you: Sorry - not supported. click If they do - let me know. I'll love taking that one to the brass. As we know - DCs work quite well virtualized today, thank you very much. Rick [msft, too] P.S. The 'not supported' thing goes for most anything that you can dream up. Believe me - PSS will try to solve nearly anything. They might laugh - but they will try. And, gladly take your $245.00, or whatever per incident is on your given current supported on not supported pain. -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Thursday, October 06, 2005 9:15 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] AD Restore Problem stupid question alert Okay so unless you are insane SBS.. images of your DCs are ixnay. What does Sun, Linux, Mac or any other competing Server OS do in their world to ensure the Kingdom easily and quickly comes back up? yeah I know they don't have AD but they have to have some competing glue, right? What have they done if anything? How to detect and recover from a USN rollback in Windows Server 2003: http://support.microsoft.com/?kbid=875495 That KB is interesting as it clearly indicates that having a DC in a Virtual Server environment is not supported... yet we SBSers have gotten word that once Exchange 2003 sp2 supports Vserver all of the parts of the 'standard' box will be supported in a virtual environment. Brett Shirley wrote: If you have any replicas of those servers, when you restore those VMWare images, you will have corrupted your forest during restore. -BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Thu, 6 Oct 2005, Carroll Frank USGR wrote: I am working my way down the VMWare path also for my ultimate DR ace in the hole. The environment is a TLD with 4 child domains. I am planning on running a single VMWare server that has virtual DCs for all 5 domains. I am going to peel off a dedicated site/vlan and put the physical VMWare server and all of the DC virt servers in that site. None of the virtual DCs are going to be GCs. The reason for the dedicated site is so I can keep people from using them for validation in production. Once I have them running, I plan to use the VM scripting to gracefully shut them down once a day and then shoot the image file of the shutdown DC off to tape, which then goes off-site. After the backup completes I then restart the virtual servers. This plays into the different hardware scenario since I can use VMWare to abstract the hardware. Of course, this whole process is the backup to the normal system state backup of all my backbone DCs. FWIW - Frank From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Coleman, Hunter Sent: Wednesday, October 05, 2005 5:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] AD Restore Problem You will still need to abandon the snapshot/image approach. Go to http://www.mail-archive.com/activedir@mail.activedir.org/ and search for usn rollback. You can get the same information by searching support.microsoft.com, but without the colorful and enlightening commentary that the list provides. Hunter List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
Re: [ActiveDir] GPO Permissions with .vbs
Interactive doesn't help in LOCALSYSTEM context for GUI apps, only CMD.EXE canpop in LOCALSYSTEM context. I like to as far as possible, use the tools which come with os itself, so using Perl for this stuff might be overkill. Anyway, for scheduling it on many computers, 1) directly running schtasks.exe against list of computers, (I suggest this method if count is small) a) create normal domain user account, with complex password, for running the task. b)create a text file containing all the comps where you want to schedule the job. say, comps.txt c) put the following text into batch file, and save the batch file in same directory as comps.txt :: Start Copy Here @ECHO OFF for /F %%A in (comps.txt) do ( echo Scheduling the task on %%A ... schtasks /S %%A /create /SC WEEKLY /D MON,TUE,WED,THU,FRI /TN mypopup /TR C:\PROGRA~1\INTERN~1\iexplore.exe -new http://www.domain.com /ST 11:00 /IT /RU runuser /RP runpasswd /F) :: End Copy Here d) Make appropriate changes in the script above, for taskname(TN), username(RU), password(RP) now from your admin workstation, make sure you are logged in with user, who has admin rights over all the comps in question. Run the batch file, it will connect to each computer and schedule the task under specified user context. once, you verify that it is all scheduled, replace the actual username, password from batch file with dummies, and save it for future use. 2) If you want to use _vbscript_, coupled with GP deployment, then u will have to hide the credentials. As others suggested, many waysto do it, make actual app in VB, or use tools like CPAU from joeware, to encrypt the credential. (http://www.joeware.net/win/free/tools/cpau.htm) I use AutoIt from (http://www.autoitscript.com/autoit3/index.php) (damn cool replacement for VB apps for small tasks) If you choose to work with AutoIt, and get stuck, let me know... -- Kamlesh On 10/8/05, joe [EMAIL PROTECTED] wrote: Oh I just chased back through this thread... You want to fire up IE, I didn't catch that before, I didn't look that close at the specific process you wanted fire, just that you wanted to fire a process. You should still be able to do this with a startup script with AT as long as you specify interactive, it should pop in the current interactive session but I would be concerned of the security context it runs in which would be localsystem. In order to schedule something in the security context of another ID you will need to be able to specify userid/password which isn't fun either since someone will probably be able to see it if they are bright. What you want is something that opens an IE window in the context of the currentuser at a specified time. I am not aware of anything that will do that. You almostneed a special app that can be launched by the user in the logon script in their security context that will sleep until the specified time and then fire the app. Here is a point where being an admin with programming skills is nice though you may be able to do this with a script. Have the script fire another process that hides itself from the task bar and pops into the screen at the designated time. I will think aboutthis. There might be a way to pull this off with a perl script. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Harding, DevonSent: Friday, October 07, 2005 4:46 PM To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] GPO Permissions with .vbs How would I use schtask to assign to more than one computer. It seems like that may be our only option. I can't believe its that difficult to get a popup of IE on ALL users desktop at a specific time. -Devon From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Kamlesh ParmarSent: Friday, October 07, 2005 2:45 PM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] GPO Permissions with .vbs This is specific to opening the internet explorer with higher privileges... (nothing to do with script runing at logon or startup) If I knew, that this scheduled job runs under Admin accountI can elevate my privileges to local admin, instantly, once the website is opened, I have to just type c:\ into address bar, (c:\ will open with FULL ACCESS) anyway, my actual point is, task will run as scheduled but the Internet explorer will never popup onto user's screenas it is running under LOCALSYSTEM account. you will need to schedule task which runs under normal user account, and AT.exe will not allow you to specify the user account.You will have to create schedule task using schtasks.exe, where u can specify the normal user account under which to run the task. But gotcha is, you will have to provide the password for user under which u want task to run.e.g. schtasks /create /SC WEEKLY /D MON,TUE,WED,THU,FRI /TN myTaskName /TR C:\PROGRA~1\INTERN~1\iexplore.exe -new http://www.slashdot.org /ST 11:00 /IT /RU runuser /RP runpasswd /Fbut schtasks saves the day as you can schedule the task remotely onto
RE: [ActiveDir] GPO Permissions with .vbs
Interactive doesn't help in LOCALSYSTEM context for GUI apps, only CMD.EXE canpop in LOCALSYSTEM context. Not sure where you picked this up, but it is incorrect. I have been doing this for a loong time. Try this if you have SOON loaded soon 60 /interactive "C:\PROGRA~1\INTERN~1\iexplore.exe -new http://www.joeware.net" If not, just create the appropriate AT command. I just did it on an XP SP2 with all of the latest patches and within a minute I had an IE window up and running focused on my web site. However, just because it can be done, isn't a recommendation to do it. In fact, for this particular task, I would recommend against using the scheduler, it is added complexity that isn't needed. I like to as far as possible, use the tools which come with os itself, so using Perl for this stuff might be overkill. I like to think of overkill as when you go overboard to accomplish something simple. Eitherin terms of permissions or actions. Every method you list below messes with changing user context and IMO added complexity in a case where it isn't necessary. As for tools in the OS itself, the work done in my other post with the perl script coupled with quiet could be done in two_vbscript_ files. There is a WMI piece that will allow you to launch additional processes including hidden processes. It willjust be longer than what I put in that post. For instance the the string comparison I did for the current to desired date would need to be done a different way or would probably take considerably more _vbscript_. But the fun thing is that for such a simple script as that (and actually even much more complex scripts), you only need two files from the perl distribution, perl.exe and perl58.dll (for the current dist, older dists may need a different dll). Both of which could be in the same folder where you have the script and quiet.exe. I have had very complex share/printer reconnection perl scripts and software delivery scripts running as logon scripts for thousands of users where perl is never loaded on the clients, the two binaries are simply in the netlogon share. I havealso had entire server build scripts done this way that take a server from nothing to fully loaded with all apps and tools in place.As long as you aren't using modules you have to import you are fine and it is very rare I use modules for that exact reason. Further, running a batch file from one machine against others for this would be simple only for a small number of machines, probably such a small amount that you could just stand up and yell across the room what people should do. As you start to scale you need far more error checking, is the machine up? Is the scheduler even running? Did the job schedule properly? All of those then require either error reporting or a loop back to hit them again. Plus it would just be plain slow unless you MTed it which you won't be doing from BAT very soon. All added complexity. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kamlesh ParmarSent: Saturday, October 08, 2005 5:58 AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] GPO Permissions with .vbs Interactive doesn't help in LOCALSYSTEM context for GUI apps, only CMD.EXE canpop in LOCALSYSTEM context. I like to as far as possible, use the tools which come with os itself, so using Perl for this stuff might be overkill. Anyway, for scheduling it on many computers, 1) directly running schtasks.exe against list of computers, (I suggest this method if count is small) a) create normal domain user account, with complex password, for running the task. b)create a text file containing all the comps where you want to schedule the job. say, comps.txt c) put the following text into batch file, and save the batch file in same directory as comps.txt :: Start Copy Here @ECHO OFF for /F %%A in (comps.txt) do ( echo Scheduling the task on %%A ... schtasks /S %%A /create /SC WEEKLY /D MON,TUE,WED,THU,FRI /TN mypopup /TR "C:\PROGRA~1\INTERN~1\iexplore.exe -new http://www.domain.com" /ST 11:00 /IT /RU runuser /RP runpasswd /F) :: End Copy Here d) Make appropriate changes in the script above, for taskname(TN), username(RU), password(RP) now from your admin workstation, make sure you are logged in with user, who has admin rights over all the comps in question. Run the batch file, it will connect to each computer and schedule the task under specified user context. once, you verify that it is all scheduled, replace the actual username, password from batch file with dummies, and save it for future use. 2) If you want to use _vbscript_, coupled with GP deployment, then u will have to hide the credentials. As others suggested, many waysto do it, make actual app in VB, or use tools like CPAU from joeware, to encrypt the credential. (http://www.joeware.net/win/free/tools/cpau.htm) I use AutoIt from (http://www.autoitscript.com/autoit3/index.php)
RE: [ActiveDir] Adding custom fields to AD
Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ:
RE: [ActiveDir] AD Restore Problem
However, to a business, you can not consider best effort as supported. A company may not be able to afford to go down a path that they may not be able to get help for a problem on. Some companies will assume that risk themselves with the understanding that they probably have another way to accomplish what they want. For instance, they have other hardware based machines with whatever isn't supported in the virtual environment or possibly they roll back to the supported way. I do think though that every time some company assumes the risk on their own because MS will not give official support for a configuration (ESX comes directly to mind) and it works great and customers don't have an issue, MS has further weakens their position as a support organization. However, that being said, I understand MS can not guarantee support for every single possible thing people will do out there. But there are times (like ESX) where the reasoning behind the lack of support seems a bit hokey from those on the outside looking in. Back to topic, anyone who hears best effort support and calls that supported is playing the wish and hope game. It is better to call it unsupported and then if the management can stomach that you can go forward with it and if there is a problem you try to get MS to help and if they help as much as they can and then fall back to We are sorry, we can not help you any longer on this then there isn't some huge surprise to anyone. MS (and everyone else) calls it best effort so that they have an official easy out. If the intent was and the ability was to support it then they would call it fully supported. Where they opt out is entirely up to them. I have been in the situations where we had to make the decision of should we go forward with this or not knowing that it is simply best effort support. Depending on how gutsy I was feeling or how safe I felt about the specific item, you make a call from there. For instance, Alliance told one of my former customers that something they were doing was unsupported in the realm of GPOs, something that had been in place and functioning perfectly for years. The customer contacted me as I was around when the design was built (wasn't my design but I liked it) and had the history. I laughed as I recalled originally getting the mechanism from MS and we were not told then it was unsupported, in fact, at the time it was the only way to do what needed to be done. MS had lost all of the history on it because the people involved then had moved on and MS has poor corporate memory like many companies. Anyway, Microsoft proposed the new solution to handle what needed to be done and quite frankly IMHO, it was a trainwreck and showed no real thought or attempt to help the customer and would have drammatically increased the complexity of the environment. The solution that had been designed several years ago, even though MS was now saying was unsupported was so elegant and worked so well and had been working for multiple years so the customer told MS they were going to continue using it. MS said that it may break in a future version and that customer X was the only one doing it. My comment to that was MS has no clue who is doing it, they didn't even remember giving out the original method in the first place to this customer which I recalled clear as day. On top of that they had people onsite daily at this customer every year since Windows 2000 was launched and had finally learned that it was being done some 5 years after the fact and called it unsupported. Pardon me if I don't exactly trust the statement that they are the only company in the world that has done it. The solution wasn't brilliant, it was simple and elegant. Anyone trying to accomplish the same thing (a common task for larger environments) and who had looked at the default configuration would have probably come up with the same design if they were looking for simple. Plus, who knows how many MS folks handed out the same tools too... Quite honestly though to wrap all of this up, everything is to some extent best effort. Just because you have paid for the product or paid for the additional service contract is no guarantee that the products will work for you in the way you want or that MS will figure out why something isn't working in the time frame you need. I have dealt with numerous issues where MS has never found root cause and we had to change how we did things and fought for numerous DCRs for functionality that in our opinion should have been there based on what the product does and lost on most of them. An IBM guy was blunt honest with me once when I was trying to track down the official VMWARE support for all of their fully supported vmware products they were pushing... He said that all support is always best effort, you can not ever fully guarantee software or even hardware will do what you expect it to do, the vendor can always say, that is by design. That is why I have the honest no-nonsense warranty up
RE: [ActiveDir] Adding custom fields to AD
Oh, and just so there is no question - see addition to my post below. (yeah - I'm not yet used to the disclaimer thingie) Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 10:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add
RE: [ActiveDir] Adding custom fields to AD
One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What do you feel is wrong with ESE (aka Jet Blue)? What's the ceiling on actual database size before it caves in (performance-wise)? Max size for an ESE DB for AD is ~16TB (8KB pages * 2147483646 max pages [1]). As for when it caves perf wise from an AD standpoint it really depends on what you are doing with it and what you have indexed from what I have seen. If someone is issuing crappy inefficient queries it will seem to be pretty slow pretty fast with relatively little data. The largest DB I have seen in production has been ~20GB and that was with W2K on a GC and a bunch of that data shouldn't have been in the AD like duplicated ACEs and misc unneeded objects, etc. Going to K3 would probably reduce that DB to about 10-12GB or better due to single instance store, cleanup would reduce it even further. One Fortune 5 company I have worked with had a K3 GC DB in the area of 5GB and that was for some 250,000 users with Exchange and multiple custom attributes. joe [1] See the docs for JetCreateDatabase - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese/jet createdatabase.asp?frame=true -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 9:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info :
RE: [ActiveDir] Adding custom fields to AD
Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he
[ActiveDir] [Fwd: [mssmallbiz] sbs podcast #3]
Apologies for the OT...but this is a podcast done by SBS's Mothership Los Colinas [PSS/CSS escalation team for SBS] Please note the discussion regarding imaging for disaster purposes and virtualiztion. Original Message Subject:[mssmallbiz] sbs podcast #3 Date: Sat, 8 Oct 2005 10:40:38 -0400 From: Vlad Mazek [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] SBS Podcast #3 http://blogs.technet.com/sbs/archive/2005/10/08/412193.aspx was uploaded earlier this morning and the best news is that they are getting some real audio equipment. So great news to some of you that have complained about the voice quality, apparently it's an 8k LiveMeeting session. They had over 250 downloads of the previous episode, over half thanks to Susan Bradley http://www.msmvps.com/bradley . Here is a brief summary of the podcast: Support for SBS in Vmware What support? - as many of you already know, PSS does not support SBS issues you face with Vmware and will request that you replicate the issue inside Virtual Server or on a real system. One caveat was that you will face performance issues but a number of people still do it. They brought up a case in which a customer runs the Terminal Server inside of a Virtual Server running on top of SBS 2003, cautioning that they had a fairly powerful system. They referenced the KB article regarding support policy Support policy for Microsoft software running in non-Microsoft hardware virtualization software: http://support.microsoft.com/default.aspx?scid=kb;en-us;897615 On whether you will actually see SBS supported in a virtual environment: because SBS components must be capable of running inside of a virtual machine there is no way to guarantee that the entire system will work unless all the components work. One example that was provided was Microsoft Exchange, part of SBS, which was not supported inside of a virtual machine until Service Pack 1. Bare metal SBS Restore People that have proper backups do not call PSS. They joked many times about how only one guy that called PSS actually had a disaster recovery scenario setup. Among best practices, SBS podcast team suggested the use of standard ntbackup in addition frequent ASR (automated system recovery) backups. SBS team cautioned against use of imaging solution as most of them do not guarantee that you can restore a domain controller and most are not recommended on a server. Disaster recovery conversation was pretty valuable, discussing active directory backups and the need for the secondary domain controller. Migrating Public Folders Podcast folks discussed several ways to migrate the public folder content without forklifting the database. One of the more popular solutions was to copy all the public folder items into a mailbox and export it as pst, then merge it back on the new server. Another solution would be to export the entire contents to a csv, which does get most of the flat text content out. Finally, they discussed the option of accessing public folders with PFDavAdmin and MFCMAPI utilities. Vlad note: If the PFDavAdmin and MFCMAPI terms are new to you please do not attempt to use these. Entourage SP2 Microsoft Entourage 2004 SP2 brings the same look feel and most options of Outlook to Entourage as a true Exchange Client. Sync speed has been improved and you're allowed to have multiple address books and calendars. Previously to SP2 opening someone elses calendar would merge the content of the two calendars together. Exciting. Other enhancements include the ability to browse the GAL and organizational structure, faster Public Folder browsing, calendar sharing, ability to setup sharing and delegation and grouping messages by thread/conversation. As for better integration as a true Exchange client: If the domain password is about to expire you will now receive a notice inside Entourage. You cannot change the password there (go through OWA) but at least you'll know about it before you're locked out of the server. Office 2003 SP2 Brief but funny discussion on Office 2003 SP2: Remember to reboot the system after you install SP2. Otherwise you will not be able to send any mail or access your outgoing items. Issue of the Office 2003 SP2 deployment via WSUS was brought up, as it apparently failed for a number of people. Podcast folks promised to investigate. DPM agent on SBS 2003 Podcast team discussed DPM and called it VSS on steroids which is a fairly accurate description. You can find more details on that here. http://www.vladville.com/2005/09/data-protection-manager-2006-released. html Pretty good podcast, even given the audio quality it was still fairly entertaining - go ahead and download it http://libsyn.com/media/sbspod/10072005insidesbs.mp3 . If it will help you any, look at this as your weekly TS2 meeting where you can ask questions and get a live response to them. -- ExchangeDefender Message Security:
Re: [ActiveDir] Adding custom fields to AD
ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o) -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick KingslanSent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes.As for why ESE - it works, it is self maintaining to a great degree, thereis very little overhead in the DB, and it is quite optimized to the type of work that is required for AD.Brettsh can certainly add more.I am one for preaching more svelte attitudes on your AD.As joe mentions -it's for authN purposes first and foremost.It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to anattribute, while the actual GPO pieces reside in SYSVOL, so not much AD -lots of FRS), etc.App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas.I, too, like joe advocateADAM.I try to sell ADAM constantly as THE solution for most anything thatdoesn't have to do with authN.Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides.Partly, theythink they have to learn something new.Partly, they don't really care ifYOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified.So, it's up to you, Mr. Admin and Mr. Architectto tell whoever wants to use your AD, no - we don't do it that way becauseit's very bad.We will use ADAM.Get used to it.Rick -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of MyloSent: Friday, October 07, 2005 8:04 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to ADThat's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworksstuff with Novell where all the application configuration information forsoftware distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning).One thing I am curious about though is why MS opted for JETas the DB ofchoice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)?Mylojoe wrote:I am going to basically say what the other said only I am going to putit this wayIF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider addingthe data to AD.IF the data is going to be needed only at a couple of sites or a singlesite, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAPdoesn't support.There is also the possibility of using app partitions but if you weregoing to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD isbecoming, in many companies, a dumping ground of all the crap that wasin all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a largecompany and thought that was silly even then.The number one most important thing for AD is to authenticate Windowsusers. Every time you dump more crap into AD you are working towards impactingthat capability or the capability to quickly restore or the ability toquickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only.Plus, I wonder how long before we hit some interesting object sizelimits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get whenoverpopulating a normal multivalue attribute (i.e. not linked) and itcausing no other attributes to be added to the object. I wonder what otherlimits like that exist. joe-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Steve ShaffSent: Tuesday, August 09, 2005 12:16 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Adding custom fields to ADGroup,My manager wanted me to check, even though, I don't think that it ispossible, but, I will present the question. He would like to add some custom fields, about 30, to AD.He wouldlike to add bio information into AD to be pulled by Sharepoint andother applications for people to read. I think that this is a waste of time, space and effort.However, it is not
Re: [ActiveDir] [Fwd: [mssmallbiz] sbs podcast #3]
I am sure it was just a slip during the summary of the podcast, but below Vlad mentions that Exchange support within Virtual Server came at SP1, that is actually SP2 as we've discussed here over the last couple of days. Phil On 10/8/05, Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] wrote: Apologies for the OT...but this is a podcast done by SBS's MothershipLos Colinas [PSS/CSS escalation team for SBS]Please note the discussion regarding imaging for disaster purposes and virtualiztion. Original Message Subject:[mssmallbiz] sbs podcast #3Date: Sat, 8 Oct 2005 10:40:38 -0400From: Vlad Mazek [EMAIL PROTECTED]Reply-To: [EMAIL PROTECTED]To: [EMAIL PROTECTED] CC: [EMAIL PROTECTED]SBS Podcast #3http://blogs.technet.com/sbs/archive/2005/10/08/412193.aspx wasuploaded earlier this morning and the best news is that they are gettingsome real audio equipment. So great news to some of you that havecomplained about the voice quality, apparently it's an 8k LiveMeeting session. They had over 250 downloads of the previous episode, over halfthanks to Susan Bradley http://www.msmvps.com/bradley .Here is a brief summary of the podcast: Support for SBS in VmwareWhat support? - as many of you already know, PSS does not support SBSissues you face with Vmware and will request that you replicate theissue inside Virtual Server or on a real system. One caveat was that you will face performance issues but a number of people still do it. Theybrought up a case in which a customer runs the Terminal Server inside ofa Virtual Server running on top of SBS 2003, cautioning that they had a fairly powerful system.They referenced the KB article regarding support policy Support policyfor Microsoft software running in non-Microsoft hardware virtualizationsoftware: http://support.microsoft.com/default.aspx?scid=kb;en-us;897615On whether you will actually see SBS supported in a virtual environment:because SBS components must be capable of running inside of a virtual machine there is no way to guarantee that the entire system will workunless all the components work. One example that was provided wasMicrosoft Exchange, part of SBS, which was not supported inside of avirtual machine until Service Pack 1. Bare metal SBS RestorePeople that have proper backups do not call PSS. They joked many timesabout how only one guy that called PSS actually had a disaster recoveryscenario setup. Among best practices, SBS podcast team suggested the use of standard ntbackup in addition frequent ASR (automated systemrecovery) backups.SBS team cautioned against use of imaging solution as most of them donot guarantee that you can restore a domain controller and most are not recommended on a server. Disaster recovery conversation was prettyvaluable, discussing active directory backups and the need for thesecondary domain controller.Migrating Public FoldersPodcast folks discussed several ways to migrate the public folder content without forklifting the database. One of the more popularsolutions was to copy all the public folder items into a mailbox andexport it as pst, then merge it back on the new server. Another solution would be to export the entire contents to a csv, which does get most ofthe flat text content out. Finally, they discussed the option ofaccessing public folders with PFDavAdmin and MFCMAPI utilities.Vlad note: If the PFDavAdmin and MFCMAPI terms are new to you please do not attempt to use these.Entourage SP2Microsoft Entourage 2004 SP2 brings the same look feel and most optionsof Outlook to Entourage as a true Exchange Client. Sync speed has beenimproved and you're allowed to have multiple address books and calendars. Previously to SP2 opening someone elses calendar would mergethe content of the two calendars together. Exciting. Other enhancementsinclude the ability to browse the GAL and organizational structure, faster Public Folder browsing, calendar sharing, ability to setupsharing and delegation and grouping messages by thread/conversation.As for better integration as a true Exchange client: If the domainpassword is about to expire you will now receive a notice inside Entourage. You cannot change the password there (go through OWA) but atleast you'll know about it before you're locked out of the server.Office 2003 SP2Brief but funny discussion on Office 2003 SP2: Remember to reboot the system after you install SP2. Otherwise you will not be able to send anymail or access your outgoing items.Issue of the Office 2003 SP2 deployment via WSUS was brought up, as itapparently failed for a number of people. Podcast folks promised to investigate.DPM agent on SBS 2003Podcast team discussed DPM and called it VSS on steroids which is afairly accurate description. You can find more details on that here. http://www.vladville.com/2005/09/data-protection-manager-2006-released.htmlPretty good podcast, even given the audio quality it was still fairlyentertaining - go ahead and download it
Re: [ActiveDir] [Fwd: [mssmallbiz] sbs podcast #3]
Correct. We're still waiting for 'official' support [along with expansion to 75 gigs of junk mail] in SP2 Phil Renouf wrote: I am sure it was just a slip during the summary of the podcast, but below Vlad mentions that Exchange support within Virtual Server came at SP1, that is actually SP2 as we've discussed here over the last couple of days. Phil On 10/8/05, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Apologies for the OT...but this is a podcast done by SBS's Mothership Los Colinas [PSS/CSS escalation team for SBS] Please note the discussion regarding imaging for disaster purposes and virtualiztion. Original Message Subject:[mssmallbiz] sbs podcast #3 Date: Sat, 8 Oct 2005 10:40:38 -0400 From: Vlad Mazek [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] CC: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] SBS Podcast #3 http://blogs.technet.com/sbs/archive/2005/10/08/412193.aspx http://blogs.technet.com/sbs/archive/2005/10/08/412193.aspx was uploaded earlier this morning and the best news is that they are getting some real audio equipment. So great news to some of you that have complained about the voice quality, apparently it's an 8k LiveMeeting session. They had over 250 downloads of the previous episode, over half thanks to Susan Bradley http://www.msmvps.com/bradley . Here is a brief summary of the podcast: Support for SBS in Vmware What support? - as many of you already know, PSS does not support SBS issues you face with Vmware and will request that you replicate the issue inside Virtual Server or on a real system. One caveat was that you will face performance issues but a number of people still do it. They brought up a case in which a customer runs the Terminal Server inside of a Virtual Server running on top of SBS 2003, cautioning that they had a fairly powerful system. They referenced the KB article regarding support policy Support policy for Microsoft software running in non-Microsoft hardware virtualization software: http://support.microsoft.com/default.aspx?scid=kb;en-us;897615 On whether you will actually see SBS supported in a virtual environment: because SBS components must be capable of running inside of a virtual machine there is no way to guarantee that the entire system will work unless all the components work. One example that was provided was Microsoft Exchange, part of SBS, which was not supported inside of a virtual machine until Service Pack 1. Bare metal SBS Restore People that have proper backups do not call PSS. They joked many times about how only one guy that called PSS actually had a disaster recovery scenario setup. Among best practices, SBS podcast team suggested the use of standard ntbackup in addition frequent ASR (automated system recovery) backups. SBS team cautioned against use of imaging solution as most of them do not guarantee that you can restore a domain controller and most are not recommended on a server. Disaster recovery conversation was pretty valuable, discussing active directory backups and the need for the secondary domain controller. Migrating Public Folders Podcast folks discussed several ways to migrate the public folder content without forklifting the database. One of the more popular solutions was to copy all the public folder items into a mailbox and export it as pst, then merge it back on the new server. Another solution would be to export the entire contents to a csv, which does get most of the flat text content out. Finally, they discussed the option of accessing public folders with PFDavAdmin and MFCMAPI utilities. Vlad note: If the PFDavAdmin and MFCMAPI terms are new to you please do not attempt to use these. Entourage SP2 Microsoft Entourage 2004 SP2 brings the same look feel and most options of Outlook to Entourage as a true Exchange Client. Sync speed has been improved and you're allowed to have multiple address books and calendars. Previously to SP2 opening someone elses calendar would merge the content of the two calendars together. Exciting. Other enhancements include the ability to browse the GAL and organizational structure, faster Public Folder browsing, calendar sharing, ability to setup sharing and delegation and grouping messages by thread/conversation. As for better integration as a true Exchange client: If the domain password is about to expire you will now receive a notice inside Entourage. You cannot change the password there (go through OWA) but at
Re: [ActiveDir] [Fwd: [mssmallbiz] sbs podcast #3]
The Official SBS Support Blog : Vlad Does an Excellent Review: http://blogs.technet.com/sbs/archive/2005/10/08/412206.aspx Actually Las Colinas misspoke :-) Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: Correct. We're still waiting for 'official' support [along with expansion to 75 gigs of junk mail] in SP2 Phil Renouf wrote: I am sure it was just a slip during the summary of the podcast, but below Vlad mentions that Exchange support within Virtual Server came at SP1, that is actually SP2 as we've discussed here over the last couple of days. Phil On 10/8/05, *Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP]* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Apologies for the OT...but this is a podcast done by SBS's Mothership Los Colinas [PSS/CSS escalation team for SBS] Please note the discussion regarding imaging for disaster purposes and virtualiztion. Original Message Subject:[mssmallbiz] sbs podcast #3 Date: Sat, 8 Oct 2005 10:40:38 -0400 From: Vlad Mazek [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] To: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] CC: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] SBS Podcast #3 http://blogs.technet.com/sbs/archive/2005/10/08/412193.aspx http://blogs.technet.com/sbs/archive/2005/10/08/412193.aspx was uploaded earlier this morning and the best news is that they are getting some real audio equipment. So great news to some of you that have complained about the voice quality, apparently it's an 8k LiveMeeting session. They had over 250 downloads of the previous episode, over half thanks to Susan Bradley http://www.msmvps.com/bradley . Here is a brief summary of the podcast: Support for SBS in Vmware What support? - as many of you already know, PSS does not support SBS issues you face with Vmware and will request that you replicate the issue inside Virtual Server or on a real system. One caveat was that you will face performance issues but a number of people still do it. They brought up a case in which a customer runs the Terminal Server inside of a Virtual Server running on top of SBS 2003, cautioning that they had a fairly powerful system. They referenced the KB article regarding support policy Support policy for Microsoft software running in non-Microsoft hardware virtualization software: http://support.microsoft.com/default.aspx?scid=kb;en-us;897615 On whether you will actually see SBS supported in a virtual environment: because SBS components must be capable of running inside of a virtual machine there is no way to guarantee that the entire system will work unless all the components work. One example that was provided was Microsoft Exchange, part of SBS, which was not supported inside of a virtual machine until Service Pack 1. Bare metal SBS Restore People that have proper backups do not call PSS. They joked many times about how only one guy that called PSS actually had a disaster recovery scenario setup. Among best practices, SBS podcast team suggested the use of standard ntbackup in addition frequent ASR (automated system recovery) backups. SBS team cautioned against use of imaging solution as most of them do not guarantee that you can restore a domain controller and most are not recommended on a server. Disaster recovery conversation was pretty valuable, discussing active directory backups and the need for the secondary domain controller. Migrating Public Folders Podcast folks discussed several ways to migrate the public folder content without forklifting the database. One of the more popular solutions was to copy all the public folder items into a mailbox and export it as pst, then merge it back on the new server. Another solution would be to export the entire contents to a csv, which does get most of the flat text content out. Finally, they discussed the option of accessing public folders with PFDavAdmin and MFCMAPI utilities. Vlad note: If the PFDavAdmin and MFCMAPI terms are new to you please do not attempt to use these. Entourage SP2 Microsoft Entourage 2004 SP2 brings the same look feel and most options of Outlook to Entourage as a true Exchange Client. Sync speed has been improved and you're allowed to have multiple address books and calendars. Previously to SP2 opening someone elses calendar would merge the content of the two calendars together. Exciting. Other enhancements include the ability to browse the GAL and organizational structure, faster Public Folder browsing, calendar sharing, ability to setup sharing and delegation and grouping messages by
RE: [ActiveDir] Adding custom fields to AD
Much of AD's heritage lies in the old Exchange directory, which was ESE-based. -gil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, October 08, 2005 8:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What do you feel is wrong with ESE (aka Jet Blue)? What's the ceiling on actual database size before it caves in (performance-wise)? Max size for an ESE DB for AD is ~16TB (8KB pages * 2147483646 max pages [1]). As for when it caves perf wise from an AD standpoint it really depends on what you are doing with it and what you have indexed from what I have seen. If someone is issuing crappy inefficient queries it will seem to be pretty slow pretty fast with relatively little data. The largest DB I have seen in production has been ~20GB and that was with W2K on a GC and a bunch of that data shouldn't have been in the AD like duplicated ACEs and misc unneeded objects, etc. Going to K3 would probably reduce that DB to about 10-12GB or better due to single instance store, cleanup would reduce it even further. One Fortune 5 company I have worked with had a K3 GC DB in the area of 5GB and that was for some 250,000 users with Exchange and multiple custom attributes. joe [1] See the docs for JetCreateDatabase - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese /jet createdatabase.asp?frame=true -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 9:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ:
[Fwd: Re: [ActiveDir] McAfee VirusScan Patch 11]
In case you are not aware of McAfee issues on DCs...there's a thread on Patch Management.org listerve Original Message Subject:Re: McAfee VirusScan Patch 11 Date: Sat, 08 Oct 2005 10:02:07 -0700 From: Kevin Severud [EMAIL PROTECTED] Reply-To: Patch Management Mailing List [EMAIL PROTECTED] To: Patch Management Mailing List [EMAIL PROTECTED] References: [EMAIL PROTECTED] Couldn't find KB43878 and VSE80P11a.EXE doesn't seem to be publicly available. It's nice that McAfee mentions this issue in their forums but it would be nice to get some direct notification. We have at least one server that has been experiencing this for over a week and have been spinning our wheels trying to fix it. Now if we could just get that hotfix... Some forum posts that discuss this issue: *Announcement:* Performance issues with patch 11 viewtopic.php?t=56112 http://forums.mcafeehelp.com/viewtopic.php?t=56112 Patch 11 performance: viewtopic.php?t=55935 http://forums.mcafeehelp.com/viewtopic.php?t=55935 Pour, Matthew wrote: KB43878 Environment: McAfee VirusScan Enterprise 8.0i Environment: Microsoft Windows Environment: Logon script that loads files from the Distributed File System (DFS) shares Symptom: Installing Patch 11 leads to increased network activity Symptom: Logon to Domain controllers intermittently fails Symptom: Logon to Domain controllers is very slow Symptom: Security Event log is filled with requests if auditing logon requests Symptom: Domain Controllers are under high CPU load Symptom: When clients log on to the domain, LSASS.EXE and possibly DFSSVC.EXE on the Domain controller takes up to 100% CPU time. Symptom: Network traces on the Domain controller show the following error: request: NT Get DFS Referral response: NT error, System, Error, Code = (549) STATUS_NOT_FOUND Change: Patch 11 for VirusScan Enterprise 8.0i was deployed to client machines. Cause: The symptoms are related to the updated file system filter driver, NAIAVF5X..SYS, but the root cause is unknown and is being investigated by McAfee Engineering. Fix: A SuperDAT package, VSE80P11a.EXE, is available from McAfee Support that reinstalls the file-system filter driver from the Patch 10 release. This is a temporary solution only until the root of this issue is identified and resolved. As this package installs an older version of the file-system filter driver, the resolved issues of Patch 11 documentation related to the file-system filter driver will not apply. Note: With VirusScan Enterprise 8.0i Patch 10 installed, the DFS network trace error appears a few times only (approximately 3-7). With VirusScan Enterprise 8.0i Patch 11 installed, this error can appear several thousand times. Note: McAfee fully supports VirusScan Enterprise 8.0i Patch 11 with the VSE80P11a..EXE hotfix package installed. If you believe you are seeing this issue, please let me know. -Original Message- From: Michael Swancott [mailto:[EMAIL PROTECTED] Sent: Friday, October 07, 2005 10:56 AM To: Patch Management Mailing List Subject: Re: McAfee VirusScan Patch 11 I spoke with my TAM on this yesterday and Patch 11a is in QA and should be ready next week. Michael Swancott ePO System Administrator Patch Management Computer Sciences Corp BAE SYSTEMS North America 603-748-0351 This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. Freedman Alan A.Freedman To: Patch Management Mailing List [EMAIL PROTECTED] @bartsandthelond cc: on.nhs.uk Subject: McAfee VirusScan Patch 11 10/07/2005 03:19 AM Please
RE: [ActiveDir] Adding custom fields to AD
I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity ofDNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Saturday, October 08, 2005 12:42 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o)-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick KingslanSent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to ADInteresting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes.As for why ESE - it works, it is self maintaining to a great degree, thereis very little overhead in the DB, and it is quite optimized to the type of work that is required for AD.Brettsh can certainly add more.I am one for preaching more svelte attitudes on your AD.As joe mentions -it's for authN purposes first and foremost.It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to anattribute, while the actual GPO pieces reside in SYSVOL, so not much AD -lots of FRS), etc.App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas.I, too, like joe advocateADAM.I try to sell ADAM constantly as THE solution for most anything thatdoesn't have to do with authN.Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides.Partly, theythink they have to learn something new.Partly, they don't really care ifYOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified.So, it's up to you, Mr. Admin and Mr. Architectto tell whoever wants to use your AD, no - we don't do it that way becauseit's very bad.We will use ADAM.Get used to it.Rick -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of MyloSent: Friday, October 07, 2005 8:04 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to ADThat's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworksstuff with Novell where all the application configuration information forsoftware distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning).One thing I am curious about though is why MS opted for JETas the DB ofchoice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)?Mylojoe wrote:I am going to basically say what the other said only I am going to putit this wayIF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider addingthe data to AD.IF the data is going to be needed only at a couple of sites or a singlesite, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAPdoesn't support.There is also the possibility of using app partitions but if you weregoing to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD isbecoming, in many companies, a dumping ground of all the crap that wasin all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a largecompany and thought that was silly even then.The number one most important thing for AD is to authenticate Windowsusers. Every time you dump more crap into AD you are working towards impactingthat capability or the capability to quickly restore or the ability toquickly add more DCs. The more I
RE: [ActiveDir] Modifying Domain Admins Administrators Group
What about people who have those groups as a primary group? 30 seconds is a long time, I could be a domain admin and have it not show in the DA member attribute in milliseconds. Also do you chase all nesting? If so how? What do you key your hash/map/associative array/dictionary on so you don't get stuck in a recursive nesting? Name? SamAccountName? Should be using DN if you aren't. When building the list of current unique members do you key off of name, samaccountname? Again, should be using DN if you aren't. The restricted groups GPO should remove a user that isn't in the list within 5 minutes on a DC. But still, in computer and hacking time, that is an eternity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Fontana Sent: Saturday, October 08, 2005 12:45 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group Call my method crude and archaic...but I have a box that just runs scripts...all day...nothing else. One of them is to do a simple dump of the domain, enterprise, and schema admins group once every 30 seconds or something and diff it against the previous run. If there's a difference I get an email. This was a 2 minute batch file I put in place because someone was added to the DA's group and decided it would be fun to try and bring up a new domain. I decided to leave it in place cause it just worked; any change to the groups and I get an email with in a few minutes. Already caught a few mistakes. The restricted groups (which are also in place) have sat for hours and not kicked the non-specified user out...then again, sometimes it kicks them out right away. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, October 07, 2005 8:06 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group I am. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, October 07, 2005 10:20 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group Joe, I actually thought you were referring to the somewhat hidden primaryGroupID issue in your previous response. Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCP+I Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: [EMAIL PROTECTED] on behalf of joe Sent: Fri 10/7/2005 6:01 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group You have to look at what the scripts and GPOs are actually doing in the background. For instance, gpo simply looks at the LDAP membership of a group, ditto many of the WMI scripts out there that monitor group membership. Not all members will be listed there. Unless those items fire at a moment that the user is listed in the member list, they may not capture the info. How long does it take to get yourself into say the domain admins group and it not be listed in the member attribute for domain admins? Maybe milliseconds? How often are the monitors and GPOs firing? Auditing can help here since it will track every change if you are willing to have the overhead of the auditing, but you have to be aware if there are any limitations in your event log scraper tool. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Crawford, Scott Sent: Friday, October 07, 2005 4:40 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group Care to elaborate on what you mean by defeated? Are you suggesting that gpo's can be overridden by a local user w/o admin rights? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, October 06, 2005 7:28 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group Both can be defeated. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, October 06, 2005 2:23 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group Use a restricted group policy, or use of one Alain Lissor's (lissware.net) scripts. You can find info on either methods by searching through the archives of this list, or you could use google ... ahem I meant msn search :) Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCP+I Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: [EMAIL PROTECTED] on behalf of Devan Pala Sent: Thu 10/6/2005 9:59 AM To:
Re: [ActiveDir] Adding custom fields to AD
I used to work at a place where WINS and DNS were used. IMO, WINS was faster in resolution and *just* worked but is not standard as DNS resolution is. DNS integration with AD is a pain and can be a hassle when troubleshooting, sometimes doing a ipconfig /flush client and flushing the DNS on the DC's to resolve an issue. SP1 has several fixes for w2k3 DNS but I'm sure something else will come up. :) I say we just use hosts files again. :( Steve - Original Message - From: joe [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Saturday, October 08, 2005 5:18 PM Subject: RE: [ActiveDir] Adding custom fields to AD I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity of DNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern Sent: Saturday, October 08, 2005 12:42 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using
Re: [ActiveDir] Adding custom fields to AD
I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondarydns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who thinks he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity ofDNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom KernSent: Saturday, October 08, 2005 12:42 PM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o) -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes.As for why ESE - it works, it is self maintaining to a great degree, thereis very little overhead in the DB, and it is quite optimized to the type of work that is required for AD.Brettsh can certainly add more.I am one for preaching more svelte attitudes on your AD.As joe mentions -it's for authN purposes first and foremost.It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to anattribute, while the actual GPO pieces reside in SYSVOL, so not much AD -lots of FRS), etc.App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas.I, too, like joe advocateADAM.I try to sell ADAM constantly as THE solution for most anything thatdoesn't have to do with authN.Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides.Partly, theythink they have to learn something new.Partly, they don't really care ifYOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified.So, it's up to you, Mr. Admin and Mr. Architectto tell whoever wants to use your AD, no - we don't do it that way becauseit's very bad.We will use ADAM.Get used to it.Rick -Original Message-From: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED] ] On Behalf Of MyloSent: Friday, October 07, 2005 8:04 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to ADThat's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information forsoftware distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JETas the DB ofchoice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylojoe wrote:I am going to basically say what the other said only I am going to putit this wayIF the data needs to be available at all locations or a majority of locations where your
RE: [ActiveDir] Modifying Domain Admins Administrators Group
I'm just using the (I believe) resource kit tool global.exe to return samaccountname of users in the group. A user who has that particular group as primary still shows up. At the time my biggest concern was ANY change. There should not be any changes made to those groups at any time with out my groups knowledge. Obviously if a group (nesting) is added I'll know about it and whip out my ruler to smack someone with. As far as the restricted groups are concerned; when I first added them to the policy it worked like a charm. After some more testing I found it was taking longer than expected...more than 15 minutes. After looking at the policy I saw that I had entered domain admins instead of domain\domain admins. I changed it and it never worked. Changed it back to just domain admins and again it usually works but I recently saw a user sit in the group for an hour or so before I removed it manually. I was however notified with in a minute of the change. Like I said, it's crude but it get's what I need done. I know that I have to deal with replication time and I could hit a DC that doesn't know about the change immediately which could delay my notification by up to a few minutes, but my biggest concern at this time are certain admins that can add to the DA's group. No need to start down that road...I walked into this and am slowly cleaning up this mess. Who the hell makes a file server a DC... Now...I have to ask...how would Joe do it? ;-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, October 08, 2005 2:31 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group What about people who have those groups as a primary group? 30 seconds is a long time, I could be a domain admin and have it not show in the DA member attribute in milliseconds. Also do you chase all nesting? If so how? What do you key your hash/map/associative array/dictionary on so you don't get stuck in a recursive nesting? Name? SamAccountName? Should be using DN if you aren't. When building the list of current unique members do you key off of name, samaccountname? Again, should be using DN if you aren't. The restricted groups GPO should remove a user that isn't in the list within 5 minutes on a DC. But still, in computer and hacking time, that is an eternity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Alex Fontana Sent: Saturday, October 08, 2005 12:45 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group Call my method crude and archaic...but I have a box that just runs scripts...all day...nothing else. One of them is to do a simple dump of the domain, enterprise, and schema admins group once every 30 seconds or something and diff it against the previous run. If there's a difference I get an email. This was a 2 minute batch file I put in place because someone was added to the DA's group and decided it would be fun to try and bring up a new domain. I decided to leave it in place cause it just worked; any change to the groups and I get an email with in a few minutes. Already caught a few mistakes. The restricted groups (which are also in place) have sat for hours and not kicked the non-specified user out...then again, sometimes it kicks them out right away. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, October 07, 2005 8:06 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group I am. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, October 07, 2005 10:20 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group Joe, I actually thought you were referring to the somewhat hidden primaryGroupID issue in your previous response. Sincerely, Dèjì Akómöláfé, MCSE+M MCSA+M MCP+I Microsoft MVP - Directory Services www.readymaids.com - we know IT www.akomolafe.com Do you now realize that Today is the Tomorrow you were worried about Yesterday? -anon From: [EMAIL PROTECTED] on behalf of joe Sent: Fri 10/7/2005 6:01 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Modifying Domain Admins Administrators Group You have to look at what the scripts and GPOs are actually doing in the background. For instance, gpo simply looks at the LDAP membership of a group, ditto many of the WMI scripts out there that monitor group membership. Not all members will be listed there. Unless those items fire at a moment that the user is listed in the member list, they may not capture the info. How long does it take to get yourself into say the domain admins group and it not be listed in the member attribute for domain admins? Maybe milliseconds? How
