A setting in AD: Redirecting CN=Computers to an administrator-specified organizational unit
1. Log on with Domain Administrator credentials in the domain where the CN=computers container is being redirected. 2. Transition the domain to the Windows Server 2003 domain in the Active Directory Users and Computers snap-in (Dsa.msc) or in the Domains and Trusts (Domains.msc) snap-in. For more information about increasing the domain functional level, click the following article number to view the article in the Microsoft Knowledge Base: 322692<http://support.microsoft.com/kb/322692/> (http://support.microsoft.com/kb/322692/ ) How to raise domain and forest functional levels in Windows Server 2003 1. Create the organizational unit container where you want computers that are created with earlier-version APIs to be located, if the desired organizational unit container does not already exist. 2. Run the Redircmp.exe file at a command prompt by using the following syntax, where container-dn is the distinguished name of the organizational unit that will become the default location for newly created computer objects that are created by down-level APIs: redircmp container-dn container-dn Redircmp.exe is installed in the %Systemroot%\System32 folder on Windows Server 2003-based or newer computers. For example, to change the default location for a computer that is created with earlier-version APIs such as Net User to the OU=mycomputers container in the CONTOSO.COM domain, use the following syntax: C:\windows\system32>redircmp ou=mycomputers,DC=contoso,dc=com Note When Redircmp.exe is run to redirect the CN=Computers container to an organizational unit that is specified by an administrator, the CN=Computers container will no longer be a protected object. This means that the Computers container can now be moved, deleted, or renamed. If you use ADSIEDIT to view attributes on the CN=Computers container, you will see that the systemflags attribute was changed from -1946157056 to 0. This is by design http://support.microsoft.com/kb/324949 From: Crawford, Scott [mailto:[email protected]] Sent: Thursday, July 01, 2010 10:43 AM To: NT System Admin Issues Subject: RE: VMWare View, How are you handling AV? (Viper to be specific) Nice. What does the moving? From: Sherry Abercrombie [mailto:[email protected]] Sent: Thursday, July 01, 2010 11:52 AM To: NT System Admin Issues Subject: Re: VMWare View, How are you handling AV? (Viper to be specific) The OU that Vipre looks at to do the automatic push has a GPO that is totally restricted, can't be logged into from the network etc etc. Only Vipre and WSUS can do anything to it while in that OU. Once it's been verified that the workstation has been updated appropriately, the computer will get moved to the actual OU that it belongs in which has the appropriate GPO's. On Thu, Jul 1, 2010 at 11:38 AM, Crawford, Scott <[email protected]<mailto:[email protected]>> wrote: So, do you just plan on not getting any viruses before it gets pushed to the client? From: N Parr [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, July 01, 2010 10:37 AM To: NT System Admin Issues Subject: RE: VMWare View, How are you handling AV? (Viper to be specific) Didn't realize it would do the detect and push, I guess that would solve my problem. Just have to keep an eye on the server and delete any old clones, but like I mentioned even that should be a problem if the clones get re-created with the same names. ________________________________ From: Sherry Abercrombie [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, July 01, 2010 10:34 AM To: NT System Admin Issues Subject: Re: VMWare View, How are you handling AV? (Viper to be specific) Vipre push was part of our standard server build out, we didn't make it part of our base os images for VMWare because of guid issues as mentioned. You can set up Vipre Enterprise to automatically detect new computers based on the OU they are put in and automatically push to it. We did this for our workstation builds, but not servers. On Thu, Jul 1, 2010 at 10:27 AM, N Parr <[email protected]<mailto:[email protected]>> wrote: Why wouldn't you treat a VM license like any other? The console would see it as a normal computer and make it count anyway. Just trying to figure out an easy way to mange it. Could create an agent install package and push it out to the clone via GPO but when we update the base image for the clone with windows updates, new applications, etc it would get wiped out. I guess if the linked clones are getting created with the same naming structure you wouldn't have to worry about deleting the clients from Viper Enterprise server when because it just sees the agents by computer name and not SID or anything. When the new clones came back up they would get the agent installed via GPO again and then start talking to the Enterprise server like normal. My rambling make sense? ________________________________ From: Jeff Cain [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, July 01, 2010 10:15 AM To: NT System Admin Issues Subject: RE: VMWare View, How are you handling AV? (Viper to be specific) N Parr, I am assuming here that you are using VIPRE Enterprise. I would recommend protecting each clone with VIPRE as the growth from definitions would be minimal, this is the best way to protect your systems and any machines they are connected to. I would also say that you should reinstall the VIPRE agent after you clone the machine to prevent the Enterprise Console from confusing the machines as they'll have the same agent GUID in the console. As far as licensing goes, I don't believe we hold VM installs against you. Thanks, Jeff Cain Technical Support Analyst Sunbelt Software Email: [email protected]<mailto:[email protected]> Voice: 1-877-757-4094 Fax: 1-727-562-5199 Web: <http://www.sunbeltsoftware.com<http://www.sunbeltsoftware.com/>> Physical Address: 33 N Garden Ave Suite 1200 Clearwater, FL 33755 United States -------------------------------------------------------- If you do not want further email from us, please forward this message to [email protected]<mailto:[email protected]> with the word 'unsubscribe' in the subject of your email. -------------------------------------------------------- Helpful Sunbelt Software Links: Knowledge Base<http://support.sunbeltsoftware.com/> Open a New Support Ticket<http://www.sunbeltsoftware.com/Support/Contact/> Sunbelt Software Product Support Communities<http://www.sunbeltsoftware.com/communities/> From: N Parr [mailto:[email protected]<mailto:[email protected]>] Sent: Thursday, July 01, 2010 11:06 AM To: NT System Admin Issues Subject: VMWare View, How are you handling AV? (Viper to be specific) So does anyone have any pointers on this? Are you just not worrying about it since you can wipe the linked clones out at any time if they get infected? I'm sill worried about handling outbreak protection. Don't care if the clone gets hosed but I don't want all my clones getting infected with something and trying to spread it around. If you install AV on the base image and don't use persistent clones then they will have to update signatures every time they boot from the day the base image was created. If you use persistent clones then their deltas will grow because of signatures being added every day. And then you've got licensing and agents on linked clones trying to update from the enterprise server with a pc name that is different than the base image they were created from. I don't think a lot of AV vendors have really thought this type of situation through. ... -- Sherry Abercrombie "Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke -- Sherry Abercrombie "Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
