Right. I meant after it's been deemed ready for use.

 

If one were so inclined, one might setup a script to move computers that
have been in the "provisioning" OU for some specified time period. I
just prefer to put it in the right OU immediately and have GPOs ensure
all needed software is installed.

 

From: David Lum [mailto:david....@nwea.org] 
Sent: Thursday, July 01, 2010 12:56 PM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be
specific)

 

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 

3.      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. 
4.      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:crawfo...@evangel.edu] 
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:saber...@gmail.com] 
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 <crawfo...@evangel.edu>
wrote:

So, do you just plan on not getting any viruses before it gets pushed to
the client?

 

From: N Parr [mailto:npar...@mortonind.com] 
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:saber...@gmail.com] 
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 <npar...@mortonind.com> 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:je...@sunbelt-software.com] 
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: supp...@sunbeltsoftware.com <mailto:supp...@sunbeltsoftware.com> 
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 listmana...@sunbelt-software.com
<mailto:listmana...@sunbelt-software.com>  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:npar...@mortonind.com] 
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/>  ~

Reply via email to