Re: VMWare View, How are you handling AV? (Viper to be specific)

[Kurt Buff]

For us it's the script that joins the computer to the domain. You can
specify which OU it joins during that process, if you use netdom (for
XP) or powershell (for Win7)

Kurt

On Thu, Jul 1, 2010 at 10:43, Crawford, Scott  wrote:
> 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 
> 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  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
> Voice: 1-877-757-4094
> Fax:   1-727-562-5199
> Web: <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 with
> the word 'unsubscribe' in the subject of your email.
> 
>
> Helpful Sunbelt Software Links:
>
>
>
> Knowledge Base
>
> Open a New Support Ticket
>
> Sunbelt Software Product Support Communities
>
>
>
> From: N Parr [mailto:npar...@mortonind.com]
> Sent: Thursday, J

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Free, Bob]

Linking and SOM are totally different concepts...to me at least.
Especially for the case of the DDP which is kind of a corner case
because certain things can only be set there. 

 

From: Webster [mailto:carlwebs...@gmail.com] 
Sent: Thursday, July 01, 2010 6:36 PM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be
specific)

 

What about the Default Domain Policy and any other GPO linked at the
Domain level?  They apply to the Computer container.  Just saying...

 

 

Webster

 

From: Sean Martin [mailto:seanmarti...@gmail.com] 
Subject: Re: VMWare View, How are you handling AV? (Viper to be
specific)

 

The default for new computer objects is the Computer Container. GPOs
can't be applied there, thus the reason you modified AD to redirect new
computer objects to an alternate OU. 

 

- Sean

 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Free, Bob]

Very often, yes. At one time we always did it that way. Now, some of our
processes work that way where certain groups can add the accounts(this
is often just batched up), other groups can join the systems to the
preexisting accounts after they have been deployed out and the
provisioning system(s),if fully automated, would have close to full
control and can create/join on the fly. Depends on the scenario, what
type and role of machine it is and where it came from as to who can do
what. For example we have some ruggedized mobile devices that can go
into the hands of relatively un-trusted contractors in an externally
facing forest that are never directly connected so the provisioning and
domain join is different from a standard desktop in an office going to a
badged knowledge worker type employee on the corp net which is still
different from a locked down Call Center system that goes in a different
OU and is more of a kiosk machine etc, etc. 

 

In our case, where machines end up in the directory is critical to the
security posture so there needs to be some rigor around the deployment
process and then the ACLs need to be in place to keep it from being
moved around where it doesn't belong but still allow for movement and
maintenance by the appropriate folks when and if it  is needed. Another
corollary someone alluded to was if you are doing GP based SW
distribution, we don't happen to us the MS GPO technology but there is a
connection to what goes on systems based on where they are. 

 

From: David Lum [mailto:david@nwea.org] 
Sent: Friday, July 02, 2010 10:41 AM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be
specific)

 

So in your scenario you'd create the machine AD account before standing
up the machine right?

 

Dave

 

From: Free, Bob [mailto:r...@pge.com] 
Sent: Friday, July 02, 2010 9:03 AM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be
specific)

 

Redirection is a rather  limited approach unless you have all your
workstations in a single OU.perhaps useful for a staging OU but I'd
prefer workstations be provisioned directly into their ultimate
destination.

 

Best practice IMO is to ACL off the computers container so it is
off-limits, set ms-DS-machineaccount quota to 0 and delegate the
respective OU's permissions directly as required for the provisioning
processes and support personnel. 

 

From: David Lum [mailto:david@nwea.org] 
Sent: Thursday, July 01, 2010 10:56 AM
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 mo

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sean Martin]

Ok yes, policies linked at the domain level will apply. We were talking
about applying specific policies to new domain members only, which can't be
done if those accounts default to the Computer Container. Therefore they're
redirected to an alternate OU.

- Sean

On Thu, Jul 1, 2010 at 5:35 PM, Webster  wrote:

>  What about the Default Domain Policy and any other GPO linked at the
> Domain level?  They apply to the Computer container.  Just saying…
>
>
>
>
>
> Webster
>
>
>
> *From:* Sean Martin [mailto:seanmarti...@gmail.com]
> *Subject:* Re: VMWare View, How are you handling AV? (Viper to be
> specific)
>
>
>
> The default for new computer objects is the Computer Container. GPOs can't
> be applied there, thus the reason you modified AD to redirect new computer
> objects to an alternate OU.
>
>
>
> - Sean
>
>
>
>
>
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: VMWare View, How are you handling AV? (Viper to be specific)

[David Lum]

So in your scenario you'd create the machine AD account before standing up the 
machine right?

Dave

From: Free, Bob [mailto:r...@pge.com]
Sent: Friday, July 02, 2010 9:03 AM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be specific)

Redirection is a rather  limited approach unless you have all your workstations 
in a single OU.perhaps useful for a staging OU but I'd prefer workstations 
be provisioned directly into their ultimate destination.

Best practice IMO is to ACL off the computers container so it is off-limits, 
set ms-DS-machineaccount quota to 0 and delegate the respective OU's 
permissions directly as required for the provisioning processes and support 
personnel.

From: David Lum [mailto:david@nwea.org]
Sent: Thursday, July 01, 2010 10:56 AM
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

 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: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 
mailto: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<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<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

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Free, Bob]

Redirection is a rather  limited approach unless you have all your
workstations in a single OU.perhaps useful for a staging OU but I'd
prefer workstations be provisioned directly into their ultimate
destination.

 

Best practice IMO is to ACL off the computers container so it is
off-limits, set ms-DS-machineaccount quota to 0 and delegate the
respective OU's permissions directly as required for the provisioning
processes and support personnel. 

 

From: David Lum [mailto:david@nwea.org] 
Sent: Thursday, July 01, 2010 10:56 AM
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 
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  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.  

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Free, Bob]

Domain\Computers is not an OU, it is a container, hence no GPO can be
linked there. That is why it is generally "not used" by most
enterprises.

 

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

 

InterestingI think I just found a hole in our deployment process, or
more accurately, re-remembered it. Sherry did you change AD to new
systems automatically go into a different OU than the default, or do you
apply those GPO's to the default \Computers OU?

David Lum // SYSTEMS ENGINEER 
NORTHWEST EVALUATION ASSOCIATION
(Desk) 971.222.1025 // (Cell) 503.267.9764

From: Sherry Abercrombie [mailto:saber...@gmail.com] 
Sent: Thursday, July 01, 2010 9: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 
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  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/> 

Su

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Webster]

What about the Default Domain Policy and any other GPO linked at the Domain
level?  They apply to the Computer container.  Just saying.

 

 

Webster

 

From: Sean Martin [mailto:seanmarti...@gmail.com] 
Subject: Re: VMWare View, How are you handling AV? (Viper to be specific)

 

The default for new computer objects is the Computer Container. GPOs can't
be applied there, thus the reason you modified AD to redirect new computer
objects to an alternate OU. 

 

- Sean


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Craig Gauss]

I havent read the whole thread of emails on this but we are running
about 70+ VDI desktops.  We run Kaspersky for AV.  It is installed on
every VDI desktop.  The one pointer I can give you from experience is to
make sure any of the tasks are staggered across the different pools you
have.  We were bringing our NetApp SAN to a crawl when we had the
updates firing off whenever an update was available, same with scans.
We now have them spread out and the performance is great.

 

 

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

 

 

 

 

 

 

 

 

 

 


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sherry Abercrombie]

No I don't.  But I'll see what I can find for you tomorrow.

On Thu, Jul 1, 2010 at 4:52 PM, David Lum  wrote:

>  Thanks – my own DA account I explicitly have as a member of no other
> groups. You don’t happen to have any of that documentation handy do you?
>
>
>
> Dave
>
>
>
> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
> *Sent:* Thursday, July 01, 2010 2:43 PM
>
> *To:* NT System Admin Issues
> *Subject:* Re: VMWare View, How are you handling AV? (Viper to be
> specific)
>
>
>
> Fought that battle back in 2002  after I went to MEC 02 and won it ;)  We
> had 2 different accounts, our normal everyday use account, that was tied to
> our Exchange mailbox had no domain admin rights.  We had a separate account
> that had domain admin rights with no email.  It did take a couple of weeks
> of digging up the official MS documentation on best practices, security etc
> to win that battle, but I did it.
>
> On Thu, Jul 1, 2010 at 4:07 PM, David Lum  wrote:
>
> We run roughly the same setup here, workstations go into completely
> different OU structure than servers. Security groups are handed similarly,
> some security groups are in an OU where only Systems Engineers can hit and
> not Service Desk, but 90% of the groups live where SD can maintain them.
>
>
>
> Now if I could get my fellow SE’s to stop being domain admin on the
> accounts they use everywhere else…they are unwilling to take on the extra
> effort to set up delegation. Grrr…
>
> *David Lum** **// *SYSTEMS ENGINEER
> NORTHWEST EVALUATION ASSOCIATION
> (Desk) 971.222.1025 *// *(Cell) 503.267.9764
>
>
>
> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
> *Sent:* Thursday, July 01, 2010 12:27 PM
>
>
> *To:* NT System Admin Issues
> *Subject:* Re: VMWare View, How are you handling AV? (Viper to be
> specific)
>
>
>
> LOL, Computer OUs were setup according to department and we had delegated
> the permissions to move computers to those department OUs to the
> Helpdesk/Desktop group so that they could manage workstations.  They could
> not manage servers ;)  So the manual intervention wasn't in my group.
>
> On Thu, Jul 1, 2010 at 2:14 PM, Crawford, Scott 
> wrote:
>
> Gotcha. A little too much manual intervention for my tastes, but yeah,
> that’s valid.
>
>
>
> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
> *Sent:* Thursday, July 01, 2010 1:25 PM
>
>
> *To:* NT System Admin Issues
> *Subject:* Re: VMWare View, How are you handling AV? (Viper to be
> specific)
>
>
>
> A person.workstations will stay in that OU until they are actually
> placed on a users desk.
>
> On Thu, Jul 1, 2010 at 12:43 PM, Crawford, Scott 
> wrote:
>
> 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 
> 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
> workstatio

RE: VMWare View, How are you handling AV? (Viper to be specific)

[David Lum]

Thanks - my own DA account I explicitly have as a member of no other groups. 
You don't happen to have any of that documentation handy do you?

Dave

From: Sherry Abercrombie [mailto:saber...@gmail.com]
Sent: Thursday, July 01, 2010 2:43 PM
To: NT System Admin Issues
Subject: Re: VMWare View, How are you handling AV? (Viper to be specific)

Fought that battle back in 2002  after I went to MEC 02 and won it ;)  We had 2 
different accounts, our normal everyday use account, that was tied to our 
Exchange mailbox had no domain admin rights.  We had a separate account that 
had domain admin rights with no email.  It did take a couple of weeks of 
digging up the official MS documentation on best practices, security etc to win 
that battle, but I did it.
On Thu, Jul 1, 2010 at 4:07 PM, David Lum 
mailto:david@nwea.org>> wrote:
We run roughly the same setup here, workstations go into completely different 
OU structure than servers. Security groups are handed similarly, some security 
groups are in an OU where only Systems Engineers can hit and not Service Desk, 
but 90% of the groups live where SD can maintain them.

Now if I could get my fellow SE's to stop being domain admin on the accounts 
they use everywhere else...they are unwilling to take on the extra effort to 
set up delegation. Grrr...
David Lum // SYSTEMS ENGINEER
NORTHWEST EVALUATION ASSOCIATION
(Desk) 971.222.1025 // (Cell) 503.267.9764

From: Sherry Abercrombie [mailto:saber...@gmail.com<mailto:saber...@gmail.com>]
Sent: Thursday, July 01, 2010 12:27 PM

To: NT System Admin Issues
Subject: Re: VMWare View, How are you handling AV? (Viper to be specific)

LOL, Computer OUs were setup according to department and we had delegated the 
permissions to move computers to those department OUs to the Helpdesk/Desktop 
group so that they could manage workstations.  They could not manage servers ;) 
 So the manual intervention wasn't in my group.
On Thu, Jul 1, 2010 at 2:14 PM, Crawford, Scott 
mailto:crawfo...@evangel.edu>> wrote:
Gotcha. A little too much manual intervention for my tastes, but yeah, that's 
valid.

From: Sherry Abercrombie [mailto:saber...@gmail.com<mailto:saber...@gmail.com>]
Sent: Thursday, July 01, 2010 1:25 PM

To: NT System Admin Issues
Subject: Re: VMWare View, How are you handling AV? (Viper to be specific)

A person.workstations will stay in that OU until they are actually placed 
on a users desk.
On Thu, Jul 1, 2010 at 12:43 PM, Crawford, Scott 
mailto:crawfo...@evangel.edu>> wrote:
Nice.

What does the moving?

From: Sherry Abercrombie [mailto:saber...@gmail.com<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 
mailto: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<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<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 
mailto: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 creat

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sherry Abercrombie]

Fought that battle back in 2002  after I went to MEC 02 and won it ;)  We
had 2 different accounts, our normal everyday use account, that was tied to
our Exchange mailbox had no domain admin rights.  We had a separate account
that had domain admin rights with no email.  It did take a couple of weeks
of digging up the official MS documentation on best practices, security etc
to win that battle, but I did it.

On Thu, Jul 1, 2010 at 4:07 PM, David Lum  wrote:

>  We run roughly the same setup here, workstations go into completely
> different OU structure than servers. Security groups are handed similarly,
> some security groups are in an OU where only Systems Engineers can hit and
> not Service Desk, but 90% of the groups live where SD can maintain them.
>
>
>
> Now if I could get my fellow SE’s to stop being domain admin on the
> accounts they use everywhere else…they are unwilling to take on the extra
> effort to set up delegation. Grrr…
>
> *David Lum** **// *SYSTEMS ENGINEER
> NORTHWEST EVALUATION ASSOCIATION
> (Desk) 971.222.1025 *// *(Cell) 503.267.9764
>
>
>
> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
> *Sent:* Thursday, July 01, 2010 12:27 PM
>
> *To:* NT System Admin Issues
> *Subject:* Re: VMWare View, How are you handling AV? (Viper to be
> specific)
>
>
>
> LOL, Computer OUs were setup according to department and we had delegated
> the permissions to move computers to those department OUs to the
> Helpdesk/Desktop group so that they could manage workstations.  They could
> not manage servers ;)  So the manual intervention wasn't in my group.
>
> On Thu, Jul 1, 2010 at 2:14 PM, Crawford, Scott 
> wrote:
>
> Gotcha. A little too much manual intervention for my tastes, but yeah,
> that’s valid.
>
>
>
> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
> *Sent:* Thursday, July 01, 2010 1:25 PM
>
>
> *To:* NT System Admin Issues
> *Subject:* Re: VMWare View, How are you handling AV? (Viper to be
> specific)
>
>
>
> A person.workstations will stay in that OU until they are actually
> placed on a users desk.
>
> On Thu, Jul 1, 2010 at 12:43 PM, Crawford, Scott 
> wrote:
>
> 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 
> 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  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 wo

RE: VMWare View, How are you handling AV? (Viper to be specific)

[David Lum]

We run roughly the same setup here, workstations go into completely different 
OU structure than servers. Security groups are handed similarly, some security 
groups are in an OU where only Systems Engineers can hit and not Service Desk, 
but 90% of the groups live where SD can maintain them.

Now if I could get my fellow SE's to stop being domain admin on the accounts 
they use everywhere else...they are unwilling to take on the extra effort to 
set up delegation. Grrr...
David Lum // SYSTEMS ENGINEER
NORTHWEST EVALUATION ASSOCIATION
(Desk) 971.222.1025 // (Cell) 503.267.9764

From: Sherry Abercrombie [mailto:saber...@gmail.com]
Sent: Thursday, July 01, 2010 12:27 PM
To: NT System Admin Issues
Subject: Re: VMWare View, How are you handling AV? (Viper to be specific)

LOL, Computer OUs were setup according to department and we had delegated the 
permissions to move computers to those department OUs to the Helpdesk/Desktop 
group so that they could manage workstations.  They could not manage servers ;) 
 So the manual intervention wasn't in my group.
On Thu, Jul 1, 2010 at 2:14 PM, Crawford, Scott 
mailto:crawfo...@evangel.edu>> wrote:
Gotcha. A little too much manual intervention for my tastes, but yeah, that's 
valid.

From: Sherry Abercrombie [mailto:saber...@gmail.com<mailto:saber...@gmail.com>]
Sent: Thursday, July 01, 2010 1:25 PM

To: NT System Admin Issues
Subject: Re: VMWare View, How are you handling AV? (Viper to be specific)

A person.workstations will stay in that OU until they are actually placed 
on a users desk.
On Thu, Jul 1, 2010 at 12:43 PM, Crawford, Scott 
mailto:crawfo...@evangel.edu>> wrote:
Nice.

What does the moving?

From: Sherry Abercrombie [mailto:saber...@gmail.com<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 
mailto: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<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<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 
mailto: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<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 

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Ben Scott]

On Thu, Jul 1, 2010 at 3:27 PM, Sherry Abercrombie  wrote:
> So the manual intervention wasn't in my group.

  I remember at Unnamed U., they called that the "grad student
algorithm".  As in, "Sure, I know an an algorithm to do easy language
recognition.  His name is 'Steve'..."

-- Ben

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sherry Abercrombie]

LOL, Computer OUs were setup according to department and we had delegated
the permissions to move computers to those department OUs to the
Helpdesk/Desktop group so that they could manage workstations.  They could
not manage servers ;)  So the manual intervention wasn't in my group.

On Thu, Jul 1, 2010 at 2:14 PM, Crawford, Scott wrote:

>  Gotcha. A little too much manual intervention for my tastes, but yeah,
> that’s valid.
>
>
>
> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
> *Sent:* Thursday, July 01, 2010 1:25 PM
>
> *To:* NT System Admin Issues
> *Subject:* Re: VMWare View, How are you handling AV? (Viper to be
> specific)
>
>
>
> A person.workstations will stay in that OU until they are actually
> placed on a users desk.
>
> On Thu, Jul 1, 2010 at 12:43 PM, Crawford, Scott 
> wrote:
>
> 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 
> 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  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
> Voice: 1-877-757-4094
> Fax:   1-727-562-5199
> Web: &

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sean Martin]

No problem. I just recently staged a new Windows 2008 Forest/Domain so
the info was still fresh in my mind.

- Sean

On Thu, Jul 1, 2010 at 10:36 AM, Sherry Abercrombie wrote:

> A, that was it.  Thanks Sean, it's been several years so I didn't
> remember that, plus I don't work there anymore..
>
>  On Thu, Jul 1, 2010 at 12:12 PM, Sean Martin wrote:
>
>>  The default for new computer objects is the Computer Container. GPOs
>> can't be applied there, thus the reason you modified AD to redirect new
>> computer objects to an alternate OU.
>>
>> - Sean
>>
>>   On Thu, Jul 1, 2010 at 9:04 AM, Sherry Abercrombie 
>> wrote:
>>
>>> Changed to go to a different OU than the default.  There was a reason why
>>> we didn't apply that GPO to the default, but I don't remember what it was
>>> now.
>>>
>>>
>>>  On Thu, Jul 1, 2010 at 11:56 AM, David Lum  wrote:
>>>
>>>>   Interesting….I think I just found a hole in our deployment process,
>>>> or more accurately, re-remembered it. Sherry did you change AD to new
>>>> systems automatically go into a different OU than the default, or do you
>>>> apply those GPO’s to the default \Computers OU?
>>>>
>>>> *David Lum** **// *SYSTEMS ENGINEER
>>>> NORTHWEST EVALUATION ASSOCIATION
>>>> (Desk) 971.222.1025 *// *(Cell) 503.267.9764
>>>>
>>>> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
>>>> *Sent:* Thursday, July 01, 2010 9: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 
>>>> 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  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 getti

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Crawford, Scott]

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 
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  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, 

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Crawford, Scott]

Gotcha. A little too much manual intervention for my tastes, but yeah,
that's valid.

 

From: Sherry Abercrombie [mailto:saber...@gmail.com] 
Sent: Thursday, July 01, 2010 1:25 PM
To: NT System Admin Issues
Subject: Re: VMWare View, How are you handling AV? (Viper to be
specific)

 

A person.workstations will stay in that OU until they are actually
placed on a users desk.  

On Thu, Jul 1, 2010 at 12:43 PM, Crawford, Scott 
wrote:

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 
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  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 y

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sherry Abercrombie]

A, that was it.  Thanks Sean, it's been several years so I didn't
remember that, plus I don't work there anymore..

On Thu, Jul 1, 2010 at 12:12 PM, Sean Martin  wrote:

> The default for new computer objects is the Computer Container. GPOs can't
> be applied there, thus the reason you modified AD to redirect new computer
> objects to an alternate OU.
>
> - Sean
>
> On Thu, Jul 1, 2010 at 9:04 AM, Sherry Abercrombie wrote:
>
>> Changed to go to a different OU than the default.  There was a reason why
>> we didn't apply that GPO to the default, but I don't remember what it was
>> now.
>>
>>
>> On Thu, Jul 1, 2010 at 11:56 AM, David Lum  wrote:
>>
>>>  Interesting….I think I just found a hole in our deployment process, or
>>> more accurately, re-remembered it. Sherry did you change AD to new systems
>>> automatically go into a different OU than the default, or do you apply those
>>> GPO’s to the default \Computers OU?
>>>
>>> *David Lum** **// *SYSTEMS ENGINEER
>>> NORTHWEST EVALUATION ASSOCIATION
>>> (Desk) 971.222.1025 *// *(Cell) 503.267.9764
>>>
>>> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
>>> *Sent:* Thursday, July 01, 2010 9: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 
>>> 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  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
>>>

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sherry Abercrombie]

A person.workstations will stay in that OU until they are actually
placed on a users desk.

On Thu, Jul 1, 2010 at 12:43 PM, Crawford, Scott wrote:

>  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 
> 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  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
> Voice: 1-877-757-4094
> Fax:   1-727-562-5199
> Web: <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 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 
> Communit

RE: VMWare View, How are you handling AV? (Viper to be specific)

[David Lum]

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: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 
mailto: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<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<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 
mailto: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 t

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Crawford, Scott]

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 
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  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 pe

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Crawford, Scott]

Yeah, I don't see any difference between a virtual and physical machine
in this instance either. But, in either case, I'd still want to
guarantee that AV is on the machine prior to a user being able to use
it. Using  GPO to deploy an MSI ensures this and is in my opinion the
better way to install agents.

 

From: N Parr [mailto:npar...@mortonind.com] 
Sent: Thursday, July 01, 2010 11:49 AM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be
specific)

 

Yes, because desktop clones are provisioned so that one+ is always
available.  So when the last unused clone is logged in to View
automatically provisions, joins it so the domain and places it in a
specified OU to await the next user needing a virtual desktop.  Then the
viper server can push the agent to it and do it's thing.  No different
than booting up a new physical desktop for the first time.  If there's a
virus running around my little network that last thing I will be worried
about is an unprotected clone getting it before AV can be auto
installed.

 



From: Crawford, Scott [mailto:crawfo...@evangel.edu] 
Sent: Thursday, July 01, 2010 11:39 AM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be
specific)

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  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.sunbelts

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sean Martin]

The default for new computer objects is the Computer Container. GPOs can't
be applied there, thus the reason you modified AD to redirect new computer
objects to an alternate OU.

- Sean

On Thu, Jul 1, 2010 at 9:04 AM, Sherry Abercrombie wrote:

> Changed to go to a different OU than the default.  There was a reason why
> we didn't apply that GPO to the default, but I don't remember what it was
> now.
>
>
> On Thu, Jul 1, 2010 at 11:56 AM, David Lum  wrote:
>
>>  Interesting….I think I just found a hole in our deployment process, or
>> more accurately, re-remembered it. Sherry did you change AD to new systems
>> automatically go into a different OU than the default, or do you apply those
>> GPO’s to the default \Computers OU?
>>
>> *David Lum** **// *SYSTEMS ENGINEER
>> NORTHWEST EVALUATION ASSOCIATION
>> (Desk) 971.222.1025 *// *(Cell) 503.267.9764
>>
>> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
>> *Sent:* Thursday, July 01, 2010 9: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 
>> 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  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
>> Enterpris

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sherry Abercrombie]

Changed to go to a different OU than the default.  There was a reason why we
didn't apply that GPO to the default, but I don't remember what it was
now.

On Thu, Jul 1, 2010 at 11:56 AM, David Lum  wrote:

>  Interesting….I think I just found a hole in our deployment process, or
> more accurately, re-remembered it. Sherry did you change AD to new systems
> automatically go into a different OU than the default, or do you apply those
> GPO’s to the default \Computers OU?
>
> *David Lum** **// *SYSTEMS ENGINEER
> NORTHWEST EVALUATION ASSOCIATION
> (Desk) 971.222.1025 *// *(Cell) 503.267.9764
>
> *From:* Sherry Abercrombie [mailto:saber...@gmail.com]
> *Sent:* Thursday, July 01, 2010 9: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 
> 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  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
> Voice: 1-877-757-4094
> Fax:   1-727-562-5199
> Web: <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.

RE: VMWare View, How are you handling AV? (Viper to be specific)

[David Lum]

InterestingI think I just found a hole in our deployment process, or more 
accurately, re-remembered it. Sherry did you change AD to new systems 
automatically go into a different OU than the default, or do you apply those 
GPO's to the default \Computers OU?
David Lum // SYSTEMS ENGINEER
NORTHWEST EVALUATION ASSOCIATION
(Desk) 971.222.1025 // (Cell) 503.267.9764
From: Sherry Abercrombie [mailto:saber...@gmail.com]
Sent: Thursday, July 01, 2010 9: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 
mailto: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<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<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 
mailto: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<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<mailto:npar...@mortonind.com>]
Sent: Thursday, July 01

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sherry Abercrombie]

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 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  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
> Voice: 1-877-757-4094
> Fax:   1-727-562-5199
> Web: <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 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'

RE: VMWare View, How are you handling AV? (Viper to be specific)

[N Parr]

Yes, because desktop clones are provisioned so that one+ is always
available.  So when the last unused clone is logged in to View
automatically provisions, joins it so the domain and places it in a
specified OU to await the next user needing a virtual desktop.  Then the
viper server can push the agent to it and do it's thing.  No different
than booting up a new physical desktop for the first time.  If there's a
virus running around my little network that last thing I will be worried
about is an unprotected clone getting it before AV can be auto
installed.



From: Crawford, Scott [mailto:crawfo...@evangel.edu] 
Sent: Thursday, July 01, 2010 11:39 AM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be
specific)



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  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
get

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Crawford, Scott]

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  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

 

 

 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: VMWare View, How are you handling AV? (Viper to be specific)

[N Parr]

So if exceed our license count because of VM's it's ok.  That's nice to
know.  A simple way for you to do this would be to have the Enterprise
server or agent just check the machine type and then report back to the
server that it's a VM.  There's plenty of places in the registry that
designate the machine type as a VM, or just the fact that VM tools are
installed.



From: Jeff Cain [mailto:je...@sunbelt-software.com] 
Sent: Thursday, July 01, 2010 10:32 AM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be
specific)



We do treat them the same. We just won't count it against you; this is a
manual process as there's no automatic way of doing it (yet). Regarding
your clones, I misunderstood and thought these were all live machines
that you just cloned and gave new names. You are correct in thinking
that you don't need to delete the agent if the machine is cloned and
only one is active at a time.

 

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:27 AM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be
specific)

 

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

RE: VMWare View, How are you handling AV? (Viper to be specific)

[N Parr]

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  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 Abercromb

Re: VMWare View, How are you handling AV? (Viper to be specific)

[Sherry Abercrombie]

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  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
> Voice: 1-877-757-4094
> Fax:   1-727-562-5199
> Web: <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 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

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Jeff Cain]

We do treat them the same. We just won't count it against you; this is a manual 
process as there's no automatic way of doing it (yet). Regarding your clones, I 
misunderstood and thought these were all live machines that you just cloned and 
gave new names. You are correct in thinking that you don't need to delete the 
agent if the machine is cloned and only one is active at a time.

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:27 AM
To: NT System Admin Issues
Subject: RE: VMWare View, How are you handling AV? (Viper to be specific)

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

RE: VMWare View, How are you handling AV? (Viper to be specific)

[N Parr]

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.

 

 
... 

 

 


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Jeff Cain]

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
Voice: 1-877-757-4094
Fax:   1-727-562-5199
Web: >
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 with
the word 'unsubscribe' in the subject of your email.

Helpful Sunbelt Software Links:

Knowledge Base
Open a New Support Ticket
Sunbelt Software Product Support 
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.





...

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~

RE: VMWare View, How are you handling AV? (Viper to be specific)

[Garcia-Moran, Carlos]

We put AV on any OS Device regardless of what it is, Virtual  or Physical if 
they are connected to the network where they can talk do any other devices. The 
risk is too great.

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.





_
This e-mail, including attachments, contains information that is
confidential and may be protected by attorney/client or other privileges.
This e-mail, including attachments, constitutes non-public information
intended to be conveyed only to the designated recipient(s). If you are not
an intended recipient, you are hereby notified that any unauthorized use,
dissemination, distribution or reproduction of this e-mail, including
attachments, is strictly prohibited and may be unlawful. If you have
received this e-mail in error, please notify me by e-mail reply and delete
the original message and any attachments from your system.
_

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~