date:20100701

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

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

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

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

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

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

RE: built-in administrators access

Mystery solved. Thanks everyone

From: Jay Dale [mailto:jay.d...@3-gig.com]
Sent: July-01-10 3:47 PM
To: NT System Admin Issues
Subject: RE: built-in administrators access

Change the local administrator password, then try it.

Jay Dale
I.T. Manager, 3GiG
Mobile: 713.299.2541
Email: jay.d...@3-gig.com

Confidentiality Notice: This e-mail, including any attached files, may contain 
confidential and/or privileged information for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any review, dissemination or copying of this e-mail and attachments, if any, or 
the information contained herein, is strictly prohibited. If you are not the 
intended recipient (or authorized to receive information for the intended 
recipient), please contact the sender by reply e-mail and delete all copies of 
this message.

From: Ara Avvali [mailto:aavv...@questrade.com]
Sent: Thursday, July 01, 2010 2:46 PM
To: NT System Admin Issues
Subject: RE: built-in administrators access

Yes

From: Damien Solodow [mailto:damien.solo...@harrison.edu]
Sent: July-01-10 3:42 PM
To: NT System Admin Issues
Subject: RE: built-in administrators access

Nope.
Does the local administrator on the desktop have the same password as the local 
administrator on the server?

From: Ara Avvali [mailto:aavv...@questrade.com]
Sent: Thursday, July 01, 2010 3:40 PM
To: NT System Admin Issues
Subject: built-in administrators access

Hello everyone,

I have discovered that the local administrator on a desktop machine that is not 
a domain member, can simply browse to domain servers c$ and access everything. 
OMG
Anyone else experiencing this?

The information in this document and attachments is confidential and is 
intended solely for the use of the named recipient. If you are not the intended 
recipient, please notify us immediately and then delete this document. All 
reasonable care has been taken to ensure the correctness of the information 
provided in this document, however it constitutes an overview and does not 
constitute advice.

While all reasonable care has been taken to avoid the transmission of viruses, 
it is the responsibility of the recipient to ensure that the onward 
transmission, opening or use of this message and any attachments will not 
adversely affect its systems or data. No responsibility is accepted by 
Questrade, Inc. in this regard and the recipient should carry out such virus 
and other checks as it considers appropriate.

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

RE: built-in administrators access

2010-07-01 Thread Jay Dale

Change the local administrator password, then try it.

Jay Dale
I.T. Manager, 3GiG
Mobile: 713.299.2541
Email: jay.d...@3-gig.com

Confidentiality Notice: This e-mail, including any attached files, may contain 
confidential and/or privileged information for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any review, dissemination or copying of this e-mail and attachments, if any, or 
the information contained herein, is strictly prohibited. If you are not the 
intended recipient (or authorized to receive information for the intended 
recipient), please contact the sender by reply e-mail and delete all copies of 
this message.


From: Ara Avvali [mailto:aavv...@questrade.com]
Sent: Thursday, July 01, 2010 2:46 PM
To: NT System Admin Issues
Subject: RE: built-in administrators access

Yes

From: Damien Solodow [mailto:damien.solo...@harrison.edu]
Sent: July-01-10 3:42 PM
To: NT System Admin Issues
Subject: RE: built-in administrators access

Nope.
Does the local administrator on the desktop have the same password as the local 
administrator on the server?

From: Ara Avvali [mailto:aavv...@questrade.com]
Sent: Thursday, July 01, 2010 3:40 PM
To: NT System Admin Issues
Subject: built-in administrators access

Hello everyone,

I have discovered that the local administrator on a desktop machine that is not 
a domain member, can simply browse to domain servers c$ and access everything. 
OMG
Anyone else experiencing this?



The information in this document and attachments is confidential and is 
intended solely for the use of the named recipient. If you are not the intended 
recipient, please notify us immediately and then delete this document. All 
reasonable care has been taken to ensure the correctness of the information 
provided in this document, however it constitutes an overview and does not 
constitute advice.

While all reasonable care has been taken to avoid the transmission of viruses, 
it is the responsibility of the recipient to ensure that the onward 
transmission, opening or use of this message and any attachments will not 
adversely affect its systems or data. No responsibility is accepted by 
Questrade, Inc. in this regard and the recipient should carry out such virus 
and other checks as it considers appropriate.













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

RE: built-in administrators access

Thanks Michael, yes the same password. So that explains it

Thank you :)

From: Michael B. Smith [mailto:mich...@smithcons.com]
Sent: July-01-10 3:42 PM
To: NT System Admin Issues
Subject: RE: built-in administrators access

Are the administrator passwords the same? If so, that's completely expected. 
"pass through authentication".

Otherwiseyou need to do some checking.

Regards,

Michael B. Smith
Consultant and Exchange MVP
http://TheEssentialExchange.com

From: Ara Avvali [mailto:aavv...@questrade.com]
Sent: Thursday, July 01, 2010 3:40 PM
To: NT System Admin Issues
Subject: built-in administrators access

Hello everyone,

I have discovered that the local administrator on a desktop machine that is not 
a domain member, can simply browse to domain servers c$ and access everything. 
OMG
Anyone else experiencing this?

The information in this document and attachments is confidential and is 
intended solely for the use of the named recipient. If you are not the intended 
recipient, please notify us immediately and then delete this document. All 
reasonable care has been taken to ensure the correctness of the information 
provided in this document, however it constitutes an overview and does not 
constitute advice.

While all reasonable care has been taken to avoid the transmission of viruses, 
it is the responsibility of the recipient to ensure that the onward 
transmission, opening or use of this message and any attachments will not 
adversely affect its systems or data. No responsibility is accepted by 
Questrade, Inc. in this regard and the recipient should carry out such virus 
and other checks as it considers appropriate.

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

RE: built-in administrators access

Yes

From: Damien Solodow [mailto:damien.solo...@harrison.edu]
Sent: July-01-10 3:42 PM
To: NT System Admin Issues
Subject: RE: built-in administrators access

Nope.
Does the local administrator on the desktop have the same password as the local 
administrator on the server?

From: Ara Avvali [mailto:aavv...@questrade.com]
Sent: Thursday, July 01, 2010 3:40 PM
To: NT System Admin Issues
Subject: built-in administrators access

Hello everyone,

I have discovered that the local administrator on a desktop machine that is not 
a domain member, can simply browse to domain servers c$ and access everything. 
OMG
Anyone else experiencing this?

The information in this document and attachments is confidential and is 
intended solely for the use of the named recipient. If you are not the intended 
recipient, please notify us immediately and then delete this document. All 
reasonable care has been taken to ensure the correctness of the information 
provided in this document, however it constitutes an overview and does not 
constitute advice.

While all reasonable care has been taken to avoid the transmission of viruses, 
it is the responsibility of the recipient to ensure that the onward 
transmission, opening or use of this message and any attachments will not 
adversely affect its systems or data. No responsibility is accepted by 
Questrade, Inc. in this regard and the recipient should carry out such virus 
and other checks as it considers appropriate.

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

RE: built-in administrators access

2010-07-01 Thread Michael B. Smith

Are the administrator passwords the same? If so, that's completely expected. 
"pass through authentication".

Otherwiseyou need to do some checking.

Regards,

Michael B. Smith
Consultant and Exchange MVP
http://TheEssentialExchange.com

From: Ara Avvali [mailto:aavv...@questrade.com]
Sent: Thursday, July 01, 2010 3:40 PM
To: NT System Admin Issues
Subject: built-in administrators access

Hello everyone,

I have discovered that the local administrator on a desktop machine that is not 
a domain member, can simply browse to domain servers c$ and access everything. 
OMG
Anyone else experiencing this?



The information in this document and attachments is confidential and is 
intended solely for the use of the named recipient. If you are not the intended 
recipient, please notify us immediately and then delete this document. All 
reasonable care has been taken to ensure the correctness of the information 
provided in this document, however it constitutes an overview and does not 
constitute advice.

While all reasonable care has been taken to avoid the transmission of viruses, 
it is the responsibility of the recipient to ensure that the onward 
transmission, opening or use of this message and any attachments will not 
adversely affect its systems or data. No responsibility is accepted by 
Questrade, Inc. in this regard and the recipient should carry out such virus 
and other checks as it considers appropriate.





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

RE: built-in administrators access

2010-07-01 Thread Damien Solodow

Nope.

Does the local administrator on the desktop have the same password as
the local administrator on the server?

From: Ara Avvali [mailto:aavv...@questrade.com] 
Sent: Thursday, July 01, 2010 3:40 PM
To: NT System Admin Issues
Subject: built-in administrators access

Hello everyone,

I have discovered that the local administrator on a desktop machine that
is not a domain member, can simply browse to domain servers c$ and
access everything. OMG 

Anyone else experiencing this? 

The information in this document and attachments is confidential and is
intended solely for the use of the named recipient. If you are not the
intended recipient, please notify us immediately and then delete this
document. All reasonable care has been taken to ensure the correctness
of the information provided in this document, however it constitutes an
overview and does not constitute advice.

While all reasonable care has been taken to avoid the transmission of
viruses, it is the responsibility of the recipient to ensure that the
onward transmission, opening or use of this message and any attachments
will not adversely affect its systems or data. No responsibility is
accepted by Questrade, Inc. in this regard and the recipient should
carry out such virus and other checks as it considers appropriate.

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

built-in administrators access

Hello everyone,

I have discovered that the local administrator on a desktop machine that is not 
a domain member, can simply browse to domain servers c$ and access everything. 
OMG
Anyone else experiencing this?



The information in this document and attachments is confidential and is 
intended solely for the use of the named recipient. If you are not the intended 
recipient, please notify us immediately and then delete this document. All 
reasonable care has been taken to ensure the correctness of the information 
provided in this document, however it constitutes an overview and does not 
constitute advice.

While all reasonable care has been taken to avoid the transmission of viruses, 
it is the responsibility of the recipient to ensure that the onward 
transmission, opening or use of this message and any attachments will not 
adversely affect its systems or data. No responsibility is accepted by 
Questrade, Inc. in this regard and the recipient should carry out such virus 
and other checks as it considers appropriate.

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

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

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: OT - IPhone to Verizon...Finally

2010-07-01 Thread Mike Gill

Hmm. Weird:

 

http://www.engadget.com/2010/05/10/confirmed-apple-and-atandt-signed-five-ye
ar-iphone-exclusivity-de/

 

-- 
Mike Gill

 

From: Jay Dale [mailto:jay.d...@3-gig.com] 
Sent: Thursday, July 01, 2010 11:18 AM
To: NT System Admin Issues
Subject: OT - IPhone to Verizon...Finally

 

http://www.bloomberg.com/news/2010-06-29/verizon-wireless-said-to-start-offe
ring-iphone-ending-at-t-s-exclusivity.html?

 

 

 

Jay Dale

I.T. Manager, 3GiG

Mobile: 713.299.2541

Email: jay.d...@3-gig.com

 

Confidentiality Notice: This e-mail, including any attached files, may
contain confidential and/or privileged information for the sole use of the
intended recipient. If you are not the intended recipient, you are hereby
notified that any review, dissemination or copying of this e-mail and
attachments, if any, or the information contained herein, is strictly
prohibited. If you are not the intended recipient (or authorized to receive
information for the intended recipient), please contact the sender by reply
e-mail and delete all copies of this message.

 

 

 

 

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

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

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

2010-07-01 Thread 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 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 machi

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

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/ ) 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, new applications, etc it would
get wiped out.  I guess i

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

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

RE: OT - IPhone to Verizon...Finally

2010-07-01 Thread Rod Trent

Or, actually make a call using the product.

-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com] 
Sent: Thursday, July 01, 2010 2:35 PM
To: NT System Admin Issues
Subject: Re: OT - IPhone to Verizon...Finally

On Thu, Jul 1, 2010 at 2:21 PM, Don Guyer  wrote:
> It's funny, I saw this on 6/29 as well, but hardly any other articles 
> about it. Probably because articles like this (from "unnamed" sources) 
> have been floating around for months.
>
> I'll believe it when I see it.

  As the saying goes, "+1".  It's all vaporware to me, until and unless I
can actually buy the product.

-- Ben

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




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

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

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
>>>
>>>
>>> *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: OT - IPhone to Verizon...Finally

On Thu, Jul 1, 2010 at 2:21 PM, Don Guyer  wrote:
> It’s funny, I saw this on 6/29 as well, but hardly any other articles about
> it. Probably because articles like this (from “unnamed” sources) have been
> floating around for months.
>
> I’ll believe it when I see it.

  As the saying goes, "+1".  It's all vaporware to me, until and
unless I can actually buy the product.

-- Ben

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

Re: Scripting -- How to Echo Spaces???

2010-07-01 Thread Andrew S. Baker

I read the original post much like Ben did, hence my responses.

Good catch on the recent posts.

-ASB: http://XeeSM.com/AndrewBaker



On Wed, Jun 30, 2010 at 3:27 PM, Carl Houseman  wrote:

> I interpreted from:
>
> >From: Derrenbacker, L. Jonathan [mailto:jderrenbac...@kshgs.com]
> >Sent: Thursday, June 10, 2010 1:17 PM
> >I'm trying to echo spaces on a line by itself"
>
> that the word "line" means an implicit line break at the end.  Your quote
> was
> an affirmation that the echo command should not output JUST the line break.
>
> Carl
>
> -Original Message-
> From: Ben Scott [mailto:mailvor...@gmail.com]
> Sent: Wednesday, June 30, 2010 7:53 AM
> To: NT System Admin Issues
> Subject: Re: Scripting -- How to Echo Spaces???
>
> On Tue, Jun 29, 2010 at 9:38 PM, Carl Houseman 
> wrote:
> > So, no?  No what?   Every echo outputs a line break.   Avoiding line
> breaks
> > was not part of the request.
>
>   I interpreted
>
> >>> It needs to actually be spaces, not a line break.
>
> as meaning it cannot contain a line break.
>
> -- Ben
>
>
>

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

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

Re: OT - IPhone to Verizon...Finally

2010-07-01 Thread Andrew S. Baker

Yes, starting in January.

Let's see what the impact is on iPhone sales.

I'm very happy with the various Android-based options myself...

-ASB: http://XeeSM.com/AndrewBaker

On Thu, Jul 1, 2010 at 2:17 PM, Jay Dale  wrote:

>
> http://www.bloomberg.com/news/2010-06-29/verizon-wireless-said-to-start-offering-iphone-ending-at-t-s-exclusivity.html
> ?
>
>
>
>
>
>
>
> *Jay Dale*
>
> I.T. Manager, 3GiG
>
> Mobile: 713.299.2541
>
> Email: jay.d...@3-gig.com
>
>
>

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

RE: OT - IPhone to Verizon...Finally

2010-07-01 Thread Don Guyer

It's funny, I saw this on 6/29 as well, but hardly any other articles
about it. Probably because articles like this (from "unnamed" sources)
have been floating around for months. 

 

I'll believe it when I see it.

 

J

 

Don Guyer

Systems Engineer - Information Services

Prudential, Fox & Roach/Trident Group

431 W. Lancaster Avenue

Devon, PA 19333

Direct: (610) 993-3299

Fax: (610) 650-5306

don.gu...@prufoxroach.com  

 

From: Jay Dale [mailto:jay.d...@3-gig.com] 
Sent: Thursday, July 01, 2010 2:18 PM
To: NT System Admin Issues
Subject: OT - IPhone to Verizon...Finally

 

http://www.bloomberg.com/news/2010-06-29/verizon-wireless-said-to-start-
offering-iphone-ending-at-t-s-exclusivity.html?

 

 

 

Jay Dale

I.T. Manager, 3GiG

Mobile: 713.299.2541

Email: jay.d...@3-gig.com

 

Confidentiality Notice: This e-mail, including any attached files, may
contain confidential and/or privileged information for the sole use of
the intended recipient. If you are not the intended recipient, you are
hereby notified that any review, dissemination or copying of this e-mail
and attachments, if any, or the information contained herein, is
strictly prohibited. If you are not the intended recipient (or
authorized to receive information for the intended recipient), please
contact the sender by reply e-mail and delete all copies of this
message.

 

 

 

 

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

OT - IPhone to Verizon...Finally

2010-07-01 Thread Jay Dale

http://www.bloomberg.com/news/2010-06-29/verizon-wireless-said-to-start-offering-iphone-ending-at-t-s-exclusivity.html?



Jay Dale
I.T. Manager, 3GiG
Mobile: 713.299.2541
Email: jay.d...@3-gig.com

Confidentiality Notice: This e-mail, including any attached files, may contain 
confidential and/or privileged information for the sole use of the intended 
recipient. If you are not the intended recipient, you are hereby notified that 
any review, dissemination or copying of this e-mail and attachments, if any, or 
the information contained herein, is strictly prohibited. If you are not the 
intended recipient (or authorized to receive information for the intended 
recipient), please contact the sender by reply e-mail and delete all copies of 
this message.



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

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/ ) 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]
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 
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?

___

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

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

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

RE: WinSXS and CBS (was: Where's my disk space)

2010-07-01 Thread Carol Fee

thanks

CFee

-Original Message-
From: Ben Scott [mailto:mailvor...@gmail.com] 
Sent: Thursday, July 01, 2010 12:57 PM
To: NT System Admin Issues
Subject: WinSXS and CBS (was: Where's my disk space)

On Thu, Jul 1, 2010 at 11:03 AM, Carol Fee  wrote:
> Wow - what the heck is all that ?

  Short version: A complete copy of every version of every Windows component.

  Longer version:

  The WinSxS folder  (%SystemRoot%\WinSxS) was originally for
"side-by-side installation" of DLLs.  Historically, when two different
programs tried to install two different, incompatible versions of a
DLL with the same name, you were just screwed.  This was colloquially
termed "DLL hell".  SxS helped multiple incompatible DLLs to co-exist
on the same system.

  In Vista, WinSxS was re-purposed/extended to support what Microsoft
calls "Component Based Servicing", or "CBS".  Windows was divided up
into components.  Each component exists as an assembly, stored in
WinSxS.  During base OS install, each and every possible assembly is
copied in full to WinSxS.  This includes components you de-selected
from install in the GUI, and also components for other Editions of
Windows.  On top of that, when an update is released, every possible
version of the updated assemblies (GDR and LDR, for each Service Pack)
get stored in WinSxS, along with all the old assemblies.  So over
time, you're likely to accumulate several copies of most of Windows in
there.

  When a Windows component is actually "installed", the target
location is just a link to the component in  WinSxS.  In theory, this
makes servicing easier, because the process is to first copy in the
new version of the assembly, then change the links.  To "uninstall",
you just change the links back.

  The one ray of sunshine in this is that the links themselves hardly
use any space, so the space apparently used by, say,
"%SystemRoot%\system32" is actually much less, since it's mostly links
to WinSxS.  But WinSxS is still typically bigger than any previous
entire install of Windows, so it's still a net loss.

  The Microsoft party line is that WinSxS cannot be moved.  It cannot
even be usefully managed, except for a very few, select scenarios,
such as removing assemblies for a previous Service Pack, or removing
incompatible components from Server Core.  One should be prepared for
WinSxS to consume at least 40 GB of disk space.

  If you think this is a crazy design, you're not alone, but Microsoft
Has Spoken, so get used to it.

  More information:

http://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx

http://blogs.technet.com/b/joscon/archive/2010/06/12/general-guidance-on-disk-provisioning-for-winsxs-growth.aspx

http://blogs.msdn.com/b/ntdebugging/archive/2008/10/21/windows-hotfixes-and-updates-how-do-they-work.aspx

http://blogs.msdn.com/b/jonwis/archive/2005/12/28/507863.aspx

http://blogs.msdn.com/b/jonwis/archive/2007/01/02/deleting-from-the-winsxs-directory.aspx

http://blogs.msdn.com/b/e7/archive/2008/11/19/disk-space.aspx

-- Ben

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

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

Re: Word/Excel DDE Slowness

2010-07-01 Thread David

We've had some related issues, but not exactly the same thing.  Only
concrete thing I found on one site was this:

"I have been playing around in my XP Pro registry and have found that the
DDE setting for various programs like Wordpad.exe (and I assume WinWord.exe)
are in the Hkey_Classes_Root section.

Under Wordpad.Document.1 there is a subkey named shell with another subkey
named open and below that a couple subkeys ONE of which is ddeexec.

I right-clicked mine and exported to a temporary location, deleted the
ddeexec subkey, rebooted and no problems running Wordpad.

Reintegrating the removed subkey involves double clicking the exported .reg
file.

So, you could experiment that far at least by finding WinWord in the Root
files list."

Other than that, all I found was several other folks with the same question.

DAF

On Thu, Jul 1, 2010 at 8:53 AM, Jason Morris  wrote:

>  We have a branch office that’s experiencing slowdowns when Opening Excel
> or Word files through Windows Explorer via double-click. We found a solution
> that involved disabling DDE for .xls files that seemed to make the computers
> go browse/open files much faster. Whenever we disable DDE, it re-enables
> itself later and automagically.
>
>
>
> Does anybody have registry or group policy fix that can be used to
> “permanently” disable DDE for specific file types?
>
>
>
> Or should I just use the Jobs method of fixing the solution? “If the
> reception is bad when you hold it like that, then stop holding it like
> that.”
>
>
>
> Thanks in advance,
>
> --
>
> Jason Morris
>
> MJMC, Inc.
>
> P: 708-225-2350
>
> F: 708-943-9015
>
>
>
>
>
>
>
>  
> --
> The pages accompanying this email transmission contain information from MJMC, 
> Inc., which
> is confidential and/or privileged. The information is to be for the use of 
> the individual
> or entity named on this cover sheet. If you are not the intended recipient, 
> you are
> hereby notified that any disclosure, dissemination, distribution, or copying 
> of this
> communication is strictly prohibited. If you received this transmission in 
> error, please
> immediately notify us by telephone so that we can arrange for the retrieval 
> of the original
> document.
>
>

-- 
David

_

"Proceed with all possible speed.  Direction to be determined later."

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

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

2010-07-01 Thread 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
>> 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

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

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

WinSXS and CBS (was: Where's my disk space)

On Thu, Jul 1, 2010 at 11:03 AM, Carol Fee wrote:
> Wow - what the heck is all that ?

Short version: A complete copy of every version of every Windows component.

Longer version:

The WinSxS folder (%SystemRoot%\WinSxS) was originally for
"side-by-side installation" of DLLs. Historically, when two different
programs tried to install two different, incompatible versions of a
DLL with the same name, you were just screwed. This was colloquially
termed "DLL hell". SxS helped multiple incompatible DLLs to co-exist
on the same system.

In Vista, WinSxS was re-purposed/extended to support what Microsoft
calls "Component Based Servicing", or "CBS". Windows was divided up
into components. Each component exists as an assembly, stored in
WinSxS. During base OS install, each and every possible assembly is
copied in full to WinSxS. This includes components you de-selected
from install in the GUI, and also components for other Editions of
Windows. On top of that, when an update is released, every possible
version of the updated assemblies (GDR and LDR, for each Service Pack)
get stored in WinSxS, along with all the old assemblies. So over
time, you're likely to accumulate several copies of most of Windows in
there.

When a Windows component is actually "installed", the target
location is just a link to the component in WinSxS. In theory, this
makes servicing easier, because the process is to first copy in the
new version of the assembly, then change the links. To "uninstall",
you just change the links back.

The one ray of sunshine in this is that the links themselves hardly
use any space, so the space apparently used by, say,
"%SystemRoot%\system32" is actually much less, since it's mostly links
to WinSxS. But WinSxS is still typically bigger than any previous
entire install of Windows, so it's still a net loss.

The Microsoft party line is that WinSxS cannot be moved. It cannot
even be usefully managed, except for a very few, select scenarios,
such as removing assemblies for a previous Service Pack, or removing
incompatible components from Server Core. One should be prepared for
WinSxS to consume at least 40 GB of disk space.

If you think this is a crazy design, you're not alone, but Microsoft
Has Spoken, so get used to it.

More information:

http://blogs.technet.com/b/askcore/archive/2008/09/17/what-is-the-winsxs-directory-in-windows-2008-and-windows-vista-and-why-is-it-so-large.aspx

http://blogs.technet.com/b/joscon/archive/2010/06/12/general-guidance-on-disk-provisioning-for-winsxs-growth.aspx

http://blogs.msdn.com/b/ntdebugging/archive/2008/10/21/windows-hotfixes-and-updates-how-do-they-work.aspx

http://blogs.msdn.com/b/jonwis/archive/2005/12/28/507863.aspx

http://blogs.msdn.com/b/jonwis/archive/2007/01/02/deleting-from-the-winsxs-directory.aspx

http://blogs.msdn.com/b/e7/archive/2008/11/19/disk-space.aspx

-- Ben

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

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 
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]
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 
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]
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: >
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 po

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

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

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

... 

-- 
Sherry Abercrombie

"Any sufficiently advanced technology is indistinguishable from magic." 
Arthur C. Clarke

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

Re: FW: Virus Bulletin enews - 1 July 2010

2010-07-01 Thread David

Hmmm, be interesting to see what Stu and company have to say.



On Thu, Jul 1, 2010 at 9:29 AM, David Lum  wrote:

> Oopsie, Sunbelt VIPRE Email Security didn't pass muster on virusbtn.com's
> latest tests
>
> David Lum // SYSTEMS ENGINEER
> NORTHWEST EVALUATION ASSOCIATION
> (Desk) 971.222.1025 // (Cell) 503.267.9764
>
> -Original Message-
> From: Virus Bulletin enews [mailto:enews-ret...@lists.virusbtn.com]
> Sent: Thursday, July 01, 2010 8:25 AM
> To: 'en...@lists.virusbtn.com'
> Subject: Virus Bulletin enews - 1 July 2010
>
> The Virus Bulletin newsletter
> July 2010 edition now available on www.virusbtn.com
>
>
> AWARD NOMINATIONS
>
> Who's made the greatest contribution to anti-malware in the last
> 10 years? Who's the best newcomer? What's been the most
> innovative idea? This year marks the 20th anniversary of the VB
> conference and by way of celebration the organizers plan to give
> six gleaming awards to members of the anti-malware industry in
> recognition of their work in the last 10 years. Make your
> nominations at
> http://www.virusbtn.com/conference/vb2010/awardnominations.xsp.
>
>
> LATEST VBSPAM AWARDS & QUADRANT
>
> In the latest VBSpam test VB's team tested a record 23 full
> anti-spam solutions, together with one reputation blacklist. The
> number of VBSpam awards earned also reached a record high of 22.
> Check out the results and the latest VBSpam quadrant at
> http://www.virusbtn.com/vbspam/results/2010/07
>
>
> AMTSOlutely fabulous
>
> Since its inception, the Anti-Malware Testing Standards
> Organization has outlined its charter, held regular meetings,
> produced a range of standards documents and continues to work
> towards raising the overall standard of testing. However, there
> is still confusion as to what the organization does and stands
> for. David Harley provides his take on what AMTSO has achieved so
> far, and what might lie ahead. Read
> http://www.virusbtn.com/vba/2010/01/vb201001-AMTSO
>
>
> JOB SEEKERS
>
> Looking for a new challenge? Current vacancies in the
> anti-malware industry include:
>
>  - Reverse Engineer - iSIGHT Partners USA
>http://www.virusbtn.com/resources/jobs/job?id=254
>
>  - Vulnerability Analyst - AVET Information and Network
>Security, Warsaw, Poland
>http://www.virusbtn.com/resources/jobs/job?id=251
>
>  - Botnet Researcher - Fortinet, Nice, France
>http://www.virusbtn.com/resources/jobs/job?id=248
>
>  - Senior Software Engineer - HCL Australia Services, Melbourne,
>Australia http://www.virusbtn.com/resources/jobs/job?id=246
>
>  - Software developer C/C++ - K7 Computing, Chennai, India
>http://www.virusbtn.com/resources/jobs/job?id=241
>
> To search for more vacancies or to advertise a vacancy free of
> charge, see http://www.virusbtn.com/resources/jobs/
>
>
> VB2010 - JOIN US IN VANCOUVER
>
> VB2010 takes place 29 September to 1 October 2010 in Vancouver,
> Canada. Alongside an exceptional line-up of international
> anti-malware and anti-spam speakers, plentiful networking
> opportunities allow delegates to share research interests and
> exchange practical tips and ideas. Register online at
> http://www.virusbtn.com/conference/vb2010/
>
>
> For subscribers, the July issue of Virus Bulletin offers:
>
>  * VBSpam comparative review: With 23 full anti-spam solutions
>on the test bench, this month's VBSpam comparative review is
>the largest to date, with a record 22 product achieving
>certification. Martijn Grooten has the details.
>http://www.virusbtn.com/vba/2010/07/vb201007-vbspam-comparative
>
>  * The dawn of the 'rogue AV testers': 'Some of the new testing
>labs that have appeared recently mimic the tactics of rogue
>AV products.' Costin Raiu, Kaspersky Lab
>http://www.virusbtn.com/vba/2010/07/vb201007-comment
>
>  * Hacking Koobface: The Koobface web server component has
>vulnerabilities that are remotely exploitable. Joey Costoya
>discusses the vulnerabilities, and explores the possibility
>of taking over the Koobface botnet.
>http://www.virusbtn.com/vba/2010/07/vb201007-koobface
>
>  * Anti-unpacker tricks - part ten: Last year, a series of
>articles described some tricks that might become common in
>the future, along with some countermeasures. Now, the series
>continues with a look at tricks that are specific to
>debuggers and emulators.
>http://www.virusbtn.com/vba/2010/07/vb201007-anti-unpackers-10
>
>  * The Indian subcontinent: part II: In 1997, Virus Bulletin
>published an overview of virus activity in the Indian
>subcontinent. The piece ended with a series of predictions.
>Andrew Lee now picks up where that article left off and
>examines where the predictions were borne out, and where they
>failed to meet reality.
>http://www.virusbtn.com/vba/2010/07/vb201007-Indian-subcontinent
>
>  * What's the deal with sender authentication? Part 2: Sender
>authentication is a hot topic in the world of email. It has a

Re: Issue with Phantom Pagefile.sys

2010-07-01 Thread David

I usually leave a small page file (maybe 16 MB) on the default C partition
in order to at least be able to create a minidump file.

David


On Thu, Jul 1, 2010 at 6:47 AM, Ziots, Edward  wrote:

>  C:\Users\eziots>reg query
> "\\ricarevuec01\HKLM\SYSTEM\Currentcontrolset\Control\
>
> Session Manager\Memory Management" /V PagingFiles
>
>
>
> HKEY_LOCAL_MACHINE\SYSTEM\Currentcontrolset\Control\Session Manager\Memory
> Manag
>
> ement
>
> PagingFilesREG_MULTI_SZd:\pagefile.sys 9214 9214
>
>
>
> So it looks like the one on the c:\ drive is really phantom and can be
> deleted.
>
>
>
> The other thing I looked at is a Kernel Memory Dump was set, but if there
> is no Paging File on C:\ specified then this isn’t going to be a viable
> option accordingly to my recollection.
>
>
>
> Thanks for the heads up about the registry location accordingly. It looks
> like after the disk cleanup is finished I should be set for disk space.
>
>
>
> Z
>
>
>
> Edward Ziots
>
> CISSP,MCSA,MCP+I,Security +,Network +,CCA
>
> Network Engineer
>
> Lifespan Organization
>
> 401-639-3505
>
> ezi...@lifespan.org
>
>
>
> *From:* Jonathan Link [mailto:jonathan.l...@gmail.com]
> *Sent:* Thursday, July 01, 2010 9:36 AM
> *To:* NT System Admin Issues
> *Subject:* Re: Issue with Phantom Pagefile.sys
>
>
>
> +1
>
> When I image a system, I regularly delete pagefile.sys.  It is recreated at
> boot.
>
> On Thu, Jul 1, 2010 at 9:03 AM, Ben Scott  wrote:
>
> On Thu, Jul 1, 2010 at 8:28 AM, Ziots, Edward  wrote:
> > I see the pagefile on the D:\ drive and after a server reboot I
> > see the updated timestamp on the d:\pagefile.sys file but I don’t see it
> on
> > the reminant c:\pagefile.sys, and this was 6GB in size, but a little
> worried
> > about deleting the file accordingly from the system and not having it
> boot
> > accordingly.
>
>  In my experience:
>
> (1) If a page file is configured but does not exist at boot, it will be
> created.
> (2) The page file is locked when in use, so you can't delete an active
> page file, so if the system lets you delete c:\pagefile.sys, it is not
> active.
>
>
> > Any idea if there is another place in the registry I can look that might
> be
> > set to keep this pagefile.sys drive on the c:\ drive
>
>  I believe all the page files should be enumerated at:
>
> Key: HKLM\System\CurrentControlSet\Control\SessionManager\MemoryManagement\
> Value: PagingFiles
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>
>
>
>
>
>
>
>
>
>
>
>


-- 
David

_


"Proceed with all possible speed.  Direction to be determined later."

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

FW: Virus Bulletin enews - 1 July 2010

Oopsie, Sunbelt VIPRE Email Security didn't pass muster on virusbtn.com's 
latest tests

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

-Original Message-
From: Virus Bulletin enews [mailto:enews-ret...@lists.virusbtn.com] 
Sent: Thursday, July 01, 2010 8:25 AM
To: 'en...@lists.virusbtn.com'
Subject: Virus Bulletin enews - 1 July 2010

The Virus Bulletin newsletter
July 2010 edition now available on www.virusbtn.com


AWARD NOMINATIONS

Who's made the greatest contribution to anti-malware in the last
10 years? Who's the best newcomer? What's been the most
innovative idea? This year marks the 20th anniversary of the VB
conference and by way of celebration the organizers plan to give
six gleaming awards to members of the anti-malware industry in
recognition of their work in the last 10 years. Make your
nominations at
http://www.virusbtn.com/conference/vb2010/awardnominations.xsp.


LATEST VBSPAM AWARDS & QUADRANT

In the latest VBSpam test VB's team tested a record 23 full
anti-spam solutions, together with one reputation blacklist. The
number of VBSpam awards earned also reached a record high of 22.
Check out the results and the latest VBSpam quadrant at
http://www.virusbtn.com/vbspam/results/2010/07


AMTSOlutely fabulous

Since its inception, the Anti-Malware Testing Standards
Organization has outlined its charter, held regular meetings,
produced a range of standards documents and continues to work
towards raising the overall standard of testing. However, there
is still confusion as to what the organization does and stands
for. David Harley provides his take on what AMTSO has achieved so
far, and what might lie ahead. Read
http://www.virusbtn.com/vba/2010/01/vb201001-AMTSO


JOB SEEKERS

Looking for a new challenge? Current vacancies in the
anti-malware industry include:

  - Reverse Engineer - iSIGHT Partners USA
http://www.virusbtn.com/resources/jobs/job?id=254

  - Vulnerability Analyst - AVET Information and Network
Security, Warsaw, Poland
http://www.virusbtn.com/resources/jobs/job?id=251

  - Botnet Researcher - Fortinet, Nice, France
http://www.virusbtn.com/resources/jobs/job?id=248

  - Senior Software Engineer - HCL Australia Services, Melbourne,
Australia http://www.virusbtn.com/resources/jobs/job?id=246

  - Software developer C/C++ - K7 Computing, Chennai, India
http://www.virusbtn.com/resources/jobs/job?id=241

To search for more vacancies or to advertise a vacancy free of
charge, see http://www.virusbtn.com/resources/jobs/


VB2010 - JOIN US IN VANCOUVER

VB2010 takes place 29 September to 1 October 2010 in Vancouver,
Canada. Alongside an exceptional line-up of international
anti-malware and anti-spam speakers, plentiful networking
opportunities allow delegates to share research interests and
exchange practical tips and ideas. Register online at
http://www.virusbtn.com/conference/vb2010/


For subscribers, the July issue of Virus Bulletin offers:

  * VBSpam comparative review: With 23 full anti-spam solutions
on the test bench, this month's VBSpam comparative review is
the largest to date, with a record 22 product achieving
certification. Martijn Grooten has the details.
http://www.virusbtn.com/vba/2010/07/vb201007-vbspam-comparative

  * The dawn of the 'rogue AV testers': 'Some of the new testing
labs that have appeared recently mimic the tactics of rogue
AV products.' Costin Raiu, Kaspersky Lab
http://www.virusbtn.com/vba/2010/07/vb201007-comment

  * Hacking Koobface: The Koobface web server component has
vulnerabilities that are remotely exploitable. Joey Costoya
discusses the vulnerabilities, and explores the possibility
of taking over the Koobface botnet.
http://www.virusbtn.com/vba/2010/07/vb201007-koobface

  * Anti-unpacker tricks - part ten: Last year, a series of
articles described some tricks that might become common in
the future, along with some countermeasures. Now, the series
continues with a look at tricks that are specific to
debuggers and emulators.
http://www.virusbtn.com/vba/2010/07/vb201007-anti-unpackers-10

  * The Indian subcontinent: part II: In 1997, Virus Bulletin
published an overview of virus activity in the Indian
subcontinent. The piece ended with a series of predictions.
Andrew Lee now picks up where that article left off and
examines where the predictions were borne out, and where they
failed to meet reality.
http://www.virusbtn.com/vba/2010/07/vb201007-Indian-subcontinent

  * What's the deal with sender authentication? Part 2: Sender
authentication is a hot topic in the world of email. It has a
number of uses and a number of suggested uses. Which ones
work in real life? Which ones don't quite measure up? Can we
use authentication to mitigate spoofing? Can we use it to
guarantee authenticity? And how do we authenticate email,
anyway? Terry Zink provides

RE: Issue with Phantom Pagefile.sys

2010-07-01 Thread Ziots, Edward

Usually use ccleaner.. J 

 

Z

 

Edward Ziots

CISSP,MCSA,MCP+I,Security +,Network +,CCA

Network Engineer

Lifespan Organization

401-639-3505

ezi...@lifespan.org

 

From: Richard Stovall [mailto:rich...@gmail.com] 
Sent: Thursday, July 01, 2010 9:59 AM
To: NT System Admin Issues
Subject: Re: Issue with Phantom Pagefile.sys

 

On Thu, Jul 1, 2010 at 9:47 AM, Ziots, Edward 
wrote:

Thanks for the heads up about the registry location accordingly. It
looks like after the disk cleanup is finished I should be set for disk
space.

This comment caught my eye.  I'm sure most know about the following
little tip, but just in case...

 

If you're using the "Disk Cleanup" app baked into XP/2003 and earlier,
and it takes forever at "Scanning: Compress old files", delete the
registry key at
"HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Co
mpress old files".  In the future Disk Cleanup will skip the compression
option completely and move straight to what you were looking for all
along.

 

Or use CCleaner.

 

 

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

RE: Weird Dell Printer issue

Found this on the Adobe site:

Only first page or first few pages of multi-page PDF files print
(Acrobat 9 and Adobe Reader 9)
Issue

Acrobat and Adobe Reader 9 only print the first few pages of multi-page
PDF documents. The printer may also print a Postscript error. 
Solution

Change the font and resource policy to Send for Each Page. 
Note: Your printer drivers must be PostScript capable to use this
procedure. 

1.Open Acrobat or Adobe Reader. 
2.Choose File >Print. 
3.Click the Advanced button. 
4.The pop-up window that appears will look different depending on what
print driver you have installed. If your driver is PostScript capable,
then there should be a PostScript Options section. 
5.In the PostScript Options section, change the "Font and Resource
Policy" dropdown to "Send for Each Page".

-Original Message-
From: Phil Brutsche [mailto:p...@optimumdata.com] 
Sent: Thursday, July 01, 2010 12:00 PM
To: NT System Admin Issues
Subject: Re: Weird Dell Printer issue

If you're using the PostScript driver for that printer it could be that
Adobe Reader is generating PDF output the printer's PS engine doesn't
like.

On 7/1/2010 9:18 AM, Steve Kelsay wrote:
> Well, we have had this issue through several Adobe reader version,
> but I will try Foxit and see what happens.
> 
> Success! The files print just fine using Foxit. Now I wonder what in
> Adobe causes just one printer to fail? Oh well. At least it works
> using Foxit, which I prefer Anyway.

-- 

Phil Brutsche
p...@optimumdata.com

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

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

Re: Weird Dell Printer issue

2010-07-01 Thread Phil Brutsche

If you're using the PostScript driver for that printer it could be that
Adobe Reader is generating PDF output the printer's PS engine doesn't like.

On 7/1/2010 9:18 AM, Steve Kelsay wrote:
> Well, we have had this issue through several Adobe reader version,
> but I will try Foxit and see what happens.
> 
> Success! The files print just fine using Foxit. Now I wonder what in
> Adobe causes just one printer to fail? Oh well. At least it works
> using Foxit, which I prefer Anyway.

-- 

Phil Brutsche
p...@optimumdata.com

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

Word/Excel DDE Slowness

2010-07-01 Thread Jason Morris

We have a branch office that's experiencing slowdowns when Opening Excel or 
Word files through Windows Explorer via double-click. We found a solution that 
involved disabling DDE for .xls files that seemed to make the computers go 
browse/open files much faster. Whenever we disable DDE, it re-enables itself 
later and automagically.

Does anybody have registry or group policy fix that can be used to 
"permanently" disable DDE for specific file types?

Or should I just use the Jobs method of fixing the solution? "If the reception 
is bad when you hold it like that, then stop holding it like that."

Thanks in advance,
--
Jason Morris
MJMC, Inc.
P: 708-225-2350
F: 708-943-9015


--
The pages accompanying this email transmission contain information from MJMC, 
Inc., which
is confidential and/or privileged. The information is to be for the use of the 
individual
or entity named on this cover sheet. If you are not the intended recipient, you 
are
hereby notified that any disclosure, dissemination, distribution, or copying of 
this
communication is strictly prohibited. If you received this transmission in 
error, please
immediately notify us by telephone so that we can arrange for the retrieval of 
the original
document.

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

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

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

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

... 

-- 
Sherry Abercrombie

"Any sufficiently advanced technology is indistinguishable from magic." 
Arthur C. Clarke

~ Finally, powerf

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


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

2010-07-01 Thread 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
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: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
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 t

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

2010-07-01 Thread 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)

2010-07-01 Thread 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! ~
~   ~

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: Where's my disk space gone ?

2010-07-01 Thread Carol Fee

Wow - what the heck is all that ?

CFee

-Original Message-
From: Mike Tavares [mailto:miketava...@comcast.net] 
Sent: Wednesday, June 30, 2010 7:37 PM
To: NT System Admin Issues
Subject: Re: Where's my disk space gone ?

Oliver,

Did you check the size of the WINSXS folder (in the C:\windows\ directory). 
You may need to show hidden files and protected operating system files to 
see it.

I know on all my 2008 boxes this is where the diskspace appears to dissapear 
into.

- Original Message - 
From: "Oliver Marshall" 
To: "NT System Admin Issues" 
Sent: Wednesday, June 30, 2010 4:06 PM
Subject: Where's my disk space gone ?

Hi,

I have a Windows 2008 server with a 100GB C partition. It has 8GB free, 
meaning 92GB is in use. However every disk space tool I use shows that only 
34GB of data is on the drive. I've tried clearing the shadow copies and that 
freed a few GB.

Any idea where the other 60'ish GB may be lurking ?

Olly

[cid:personal229.jpg]

[cid:g2supportsmall_250x58border4823.png]

Network Support
Online Backups
Server Management

Tel: 0845 307 3443
Email: oliver.marsh...@g2support.com
Web: http://www.g2support.com
Twitter: g2support
Newsletter: http://www.g2support.com/newsletter
Mail: 2 Roundhill Road, Brighton, Sussex, BN2 3RF

G2 Support LLP is registered at Mill House, 103 Holmes Avenue, HOVE
BN3 7LE. Our registered company number is OC316341.

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

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

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

RE: Weird Dell Printer issue

2010-07-01 Thread Carol Fee

What about calling Dell Tech Support.  I bet they've heard this before.

CFee

-Original Message-
From: Steve Kelsay [mailto:kels...@sctax.org] 
Sent: Thursday, July 01, 2010 10:19 AM
To: NT System Admin Issues
Subject: RE: Weird Dell Printer issue

OK, I will keep you informed!

-Original Message-
From: John Aldrich [mailto:jaldr...@blueridgecarpet.com] 
Sent: Thursday, July 01, 2010 9:33 AM
To: NT System Admin Issues
Subject: RE: Weird Dell Printer issue

Steve,
If you ever get the solution, please let me know. I have one Dell laser
printer and it exhibits the same behavior. Fortunately, we have a big
Kyocera MFP just a few feet away in the common area so it's not a huge
deal.. :-)

-Original Message-
From: Steve Kelsay [mailto:kels...@sctax.org] 
Sent: Thursday, July 01, 2010 9:09 AM
To: NT System Admin Issues
Subject: RE: Weird Dell Printer issue

Thanks for the information. The failure to print is on EVERY pdf, not just
one, so I do not believe it is the file, and they do print fine on all other
printers. 

No big deal, I will get hold of Dell, but I thought it might be a universal
issue someone had the answer to on the tips of their fingertips.

Thanks. I did try these remedies with no success. Since we have other
printers, it is just a bother that I am tired of dealing with.

-Original Message-
From: HELP_PC [mailto:g...@enter.it] 
Sent: Thursday, July 01, 2010 8:56 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Another option suggested in a forum

In Printer preferences, select Advanced, press the +-sign at Postscript
Options and choose Optimize for Speed instead of Encapsulted PostScript

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org] 
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of
any PDF. I don't see any settings that might affect that, and the PDFs print
fine on other printers. What is different about PDF files that might cause
this? 

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

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

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

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

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

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

RE: Weird Dell Printer issue

2010-07-01 Thread John Aldrich

Ahh... I have been upgrading all my users to SumatraPDF whenever I work on
their computers. I may make a special effort to move our payroll lady (the
one with the Dell printer) over to Sumatra and see if she's able to print
PDFs. :-)



-Original Message-
From: Steve Kelsay [mailto:kels...@sctax.org] 
Sent: Thursday, July 01, 2010 10:18 AM
To: NT System Admin Issues
Subject: RE: Weird Dell Printer issue

Well, we have had this issue through several Adobe reader version, but I
will try Foxit and see what happens.

Success! The files print just fine using Foxit. Now I wonder what in Adobe
causes just one printer to fail? Oh well. At least it works using Foxit,
which I prefer Anyway.

-Original Message-
From: Terry Dickson [mailto:te...@treasurer.state.ks.us] 
Sent: Thursday, July 01, 2010 9:34 AM
To: NT System Admin Issues
Subject: RE: Weird Dell Printer issue

What are you using to print the PDF's?  We had a similar issue several years
ago, and it was all tied to the version of Adobe Reader we were using.
Change the version and print  problems magically cleared up.

-Original Message-
From: HELP_PC [mailto:g...@enter.it] 
Sent: Thursday, July 01, 2010 8:19 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Last chance is to print as image 


GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org]
Inviato: giovedì 1 luglio 2010 15.09
A: NT System Admin Issues
Oggetto: RE: Weird Dell Printer issue

Thanks for the information. The failure to print is on EVERY pdf, not just
one, so I do not believe it is the file, and they do print fine on all other
printers. 

No big deal, I will get hold of Dell, but I thought it might be a universal
issue someone had the answer to on the tips of their fingertips.

Thanks. I did try these remedies with no success. Since we have other
printers, it is just a bother that I am tired of dealing with.

-Original Message-
From: HELP_PC [mailto:g...@enter.it]
Sent: Thursday, July 01, 2010 8:56 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Another option suggested in a forum

 
In Printer preferences, select Advanced, press the +-sign at Postscript
Options and choose Optimize for Speed instead of Encapsulted PostScript

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org]
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of
any PDF. I don't see any settings that might affect that, and the PDFs print
fine on other printers. What is different about PDF files that might cause
this? 

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

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


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

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


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


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



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

RE: Weird Dell Printer issue

Well, we have had this issue through several Adobe reader version, but I will 
try Foxit and see what happens.

Success! The files print just fine using Foxit. Now I wonder what in Adobe 
causes just one printer to fail? Oh well. At least it works using Foxit, which 
I prefer Anyway.

-Original Message-
From: Terry Dickson [mailto:te...@treasurer.state.ks.us] 
Sent: Thursday, July 01, 2010 9:34 AM
To: NT System Admin Issues
Subject: RE: Weird Dell Printer issue

What are you using to print the PDF's?  We had a similar issue several years 
ago, and it was all tied to the version of Adobe Reader we were using.  Change 
the version and print  problems magically cleared up.

-Original Message-
From: HELP_PC [mailto:g...@enter.it] 
Sent: Thursday, July 01, 2010 8:19 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Last chance is to print as image 


GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org]
Inviato: giovedì 1 luglio 2010 15.09
A: NT System Admin Issues
Oggetto: RE: Weird Dell Printer issue

Thanks for the information. The failure to print is on EVERY pdf, not just one, 
so I do not believe it is the file, and they do print fine on all other 
printers. 

No big deal, I will get hold of Dell, but I thought it might be a universal 
issue someone had the answer to on the tips of their fingertips.

Thanks. I did try these remedies with no success. Since we have other printers, 
it is just a bother that I am tired of dealing with.

-Original Message-
From: HELP_PC [mailto:g...@enter.it]
Sent: Thursday, July 01, 2010 8:56 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Another option suggested in a forum

 
In Printer preferences, select Advanced, press the +-sign at Postscript Options 
and choose Optimize for Speed instead of Encapsulted PostScript

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org]
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of any 
PDF. I don't see any settings that might affect that, and the PDFs print fine 
on other printers. What is different about PDF files that might cause this? 

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

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


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

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


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


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

RE: Weird Dell Printer issue

OK, I will keep you informed!

-Original Message-
From: John Aldrich [mailto:jaldr...@blueridgecarpet.com] 
Sent: Thursday, July 01, 2010 9:33 AM
To: NT System Admin Issues
Subject: RE: Weird Dell Printer issue

Steve,
If you ever get the solution, please let me know. I have one Dell laser
printer and it exhibits the same behavior. Fortunately, we have a big
Kyocera MFP just a few feet away in the common area so it's not a huge
deal.. :-)

-Original Message-
From: Steve Kelsay [mailto:kels...@sctax.org] 
Sent: Thursday, July 01, 2010 9:09 AM
To: NT System Admin Issues
Subject: RE: Weird Dell Printer issue

Thanks for the information. The failure to print is on EVERY pdf, not just
one, so I do not believe it is the file, and they do print fine on all other
printers. 

No big deal, I will get hold of Dell, but I thought it might be a universal
issue someone had the answer to on the tips of their fingertips.

Thanks. I did try these remedies with no success. Since we have other
printers, it is just a bother that I am tired of dealing with.

-Original Message-
From: HELP_PC [mailto:g...@enter.it] 
Sent: Thursday, July 01, 2010 8:56 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Another option suggested in a forum

In Printer preferences, select Advanced, press the +-sign at Postscript
Options and choose Optimize for Speed instead of Encapsulted PostScript

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org] 
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of
any PDF. I don't see any settings that might affect that, and the PDFs print
fine on other printers. What is different about PDF files that might cause
this? 

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

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

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

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

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

Re: Optimum Online Ultra for small business anyone

2010-07-01 Thread Roger Wright

Sounds like marketing hype to me.

>From their site:
" Due to configuration of available equipment, Static IP customers
will experience speed performance limitations. Many factors affect
speed. Actual speeds may vary and are not guaranteed."


Die dulci fruere!

Roger Wright
___




On Thu, Jul 1, 2010 at 7:38 AM, justino garcia  wrote:
> Is anyone using Optimum Online Ultra a small office or even for home use?
> They claim they are offering "you will enjoy speeds up to 101 Mbps
> downstream and up to 15 Mbps upstream!", is this true?
> I know that bandwidth isn't guaranteed, with Optiumum online, but how does
> this fair?  Is it worth the extra money per month
> http://www.optimum.com/online/ultra.jsp
>
> --
> Justin
> IT-TECH
>
>
>
>

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

Re: Issue with Phantom Pagefile.sys

2010-07-01 Thread Richard Stovall

On Thu, Jul 1, 2010 at 9:47 AM, Ziots, Edward  wrote:

>  Thanks for the heads up about the registry location accordingly. It looks
> like after the disk cleanup is finished I should be set for disk space.
>
This comment caught my eye.  I'm sure most know about the following little
tip, but just in case...

If you're using the "Disk Cleanup" app baked into XP/2003 and earlier, and
it takes forever at "Scanning: Compress old files", delete the registry key
at
"HKLM\Software\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Compress
old files".  In the future Disk Cleanup will skip the compression option
completely and move straight to what you were looking for all along.

Or use CCleaner.

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

Re: Where's my disk space gone ?

2010-07-01 Thread Jonathan Link

No on seems to be mentioning running the app, command prompt or
whatever with elevated privileges.  If UAC is on, and you aren't prompted to
do so, you need to select run as administrator yourself.



On Wed, Jun 30, 2010 at 11:05 PM, Mike Hoffman  wrote:

>  When you run your tool of choice to see the disk space is it running as
> administrator? If you use something like defraggler it will show all the
> space and whatever is eating the space will be fragmenting as it grows. It’s
> not unusual for an SBS box in this situation to have 50GB+ of IIS log files
> for all WSUS activity.
>
>
>
> See:
> http://msmvps.com/blogs/bradley/archive/2010/01/11/watch-that-wsus-administrator-log-file-location.aspxfor
>  a detailed run through.
>
>
>
> Mike
>
>
>
> *From:* James Hill [mailto:james.h...@superamart.com.au]
> *Sent:* 30 June 2010 22:37
>
> *To:* NT System Admin Issues
> *Subject:* RE: Where's my disk space gone ?
>
>
>
> Sounds like you have some large files in areas that you don’t have
> permission to.  This is not that unusual in 2008.
>
>
>
> Some of the areas to check:-
>
>
>
> · Problem Reports.  Those things can be huge.  Open “Problem
> Reports and Solutions” and then click on “Clear solution and problem
> history”.
>
> · Recycle Bins (have any folder redirection going on?  Users
> deleted large files sitting in their recycle bins on the server).  Turn on
> viewing of protected operating system files and have a browse around.
>
> · IIS Logs  c:\inetpub\logs\logfiles\ then check each folder in
> there.  If you haven’t browsed into those folders and clicked on the
> security prompts to get permission to view the contents then a folder size
> query WON’T show the actual size of the folder/s.
>
> · C:\windows\temp
>
>
>
> Another option is to use the File Server Resource Manager and run some
> reports on large files etc.  That will show up anything no matter what
> permissions are set.
>
>
>
>
>
>
>
> *From:* Oliver Marshall [mailto:oliver.marsh...@g2support.com]
> *Sent:* Thursday, 1 July 2010 6:06 AM
> *To:* NT System Admin Issues
> *Subject:* Where's my disk space gone ?
>
>
>
> Hi,
>
>
>
> I have a Windows 2008 server with a 100GB C partition. It has 8GB free,
> meaning 92GB is in use. However every disk space tool I use shows that only
> 34GB of data is on the drive. I've tried clearing the shadow copies and that
> freed a few GB.
>
>
>
> Any idea where the other 60'ish GB may be lurking ?
>
>
>
> Olly
>
>
>
>
>
>  Network Support
> Online Backups
> Server Management
>
> Tel: 0845 307 3443
>
> Email: oliver.marsh...@g2support.com
>
> Web: http://www.g2support.com
>
> Twitter: g2support 
>
> Newsletter: http://www.g2support.com/newsletter
>
> Mail: 2 Roundhill Road, Brighton, Sussex, BN2 3RF
>
>
>
> G2 Support LLP is registered at Mill House, 103 Holmes Avenue, HOVE
>
> BN3 7LE. Our registered company number is OC316341.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

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

RE: Issue with Phantom Pagefile.sys

2010-07-01 Thread Ziots, Edward

C:\Users\eziots>reg query
"\\ricarevuec01\HKLM\SYSTEM\Currentcontrolset\Control\

Session Manager\Memory Management" /V PagingFiles

HKEY_LOCAL_MACHINE\SYSTEM\Currentcontrolset\Control\Session
Manager\Memory Manag

ement

PagingFilesREG_MULTI_SZd:\pagefile.sys 9214 9214

So it looks like the one on the c:\ drive is really phantom and can be
deleted. 

The other thing I looked at is a Kernel Memory Dump was set, but if
there is no Paging File on C:\ specified then this isn't going to be a
viable option accordingly to my recollection. 

Thanks for the heads up about the registry location accordingly. It
looks like after the disk cleanup is finished I should be set for disk
space. 

Z

Edward Ziots

CISSP,MCSA,MCP+I,Security +,Network +,CCA

Network Engineer

Lifespan Organization

401-639-3505

ezi...@lifespan.org

From: Jonathan Link [mailto:jonathan.l...@gmail.com] 
Sent: Thursday, July 01, 2010 9:36 AM
To: NT System Admin Issues
Subject: Re: Issue with Phantom Pagefile.sys

+1

When I image a system, I regularly delete pagefile.sys.  It is recreated
at boot.  

On Thu, Jul 1, 2010 at 9:03 AM, Ben Scott  wrote:

On Thu, Jul 1, 2010 at 8:28 AM, Ziots, Edward 
wrote:
> I see the pagefile on the D:\ drive and after a server reboot I
> see the updated timestamp on the d:\pagefile.sys file but I don't see
it on
> the reminant c:\pagefile.sys, and this was 6GB in size, but a little
worried
> about deleting the file accordingly from the system and not having it
boot
> accordingly.

 In my experience:

(1) If a page file is configured but does not exist at boot, it will be
created.
(2) The page file is locked when in use, so you can't delete an active
page file, so if the system lets you delete c:\pagefile.sys, it is not
active.

> Any idea if there is another place in the registry I can look that
might be
> set to keep this pagefile.sys drive on the c:\ drive

 I believe all the page files should be enumerated at:

Key:
HKLM\System\CurrentControlSet\Control\SessionManager\MemoryManagement\
Value: PagingFiles

-- Ben

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

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

Re: Issue with Phantom Pagefile.sys

2010-07-01 Thread Jonathan Link

+1
When I image a system, I regularly delete pagefile.sys.  It is recreated at
boot.

On Thu, Jul 1, 2010 at 9:03 AM, Ben Scott  wrote:

> On Thu, Jul 1, 2010 at 8:28 AM, Ziots, Edward  wrote:
> > I see the pagefile on the D:\ drive and after a server reboot I
> > see the updated timestamp on the d:\pagefile.sys file but I don’t see it
> on
> > the reminant c:\pagefile.sys, and this was 6GB in size, but a little
> worried
> > about deleting the file accordingly from the system and not having it
> boot
> > accordingly.
>
>  In my experience:
>
> (1) If a page file is configured but does not exist at boot, it will be
> created.
> (2) The page file is locked when in use, so you can't delete an active
> page file, so if the system lets you delete c:\pagefile.sys, it is not
> active.
>
> > Any idea if there is another place in the registry I can look that might
> be
> > set to keep this pagefile.sys drive on the c:\ drive
>
>  I believe all the page files should be enumerated at:
>
> Key: HKLM\System\CurrentControlSet\Control\SessionManager\MemoryManagement\
> Value: PagingFiles
>
> -- Ben
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>
>

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

RE: Weird Dell Printer issue

2010-07-01 Thread Terry Dickson

What are you using to print the PDF's?  We had a similar issue several years 
ago, and it was all tied to the version of Adobe Reader we were using.  Change 
the version and print  problems magically cleared up.

-Original Message-
From: HELP_PC [mailto:g...@enter.it] 
Sent: Thursday, July 01, 2010 8:19 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Last chance is to print as image 

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org]
Inviato: giovedì 1 luglio 2010 15.09
A: NT System Admin Issues
Oggetto: RE: Weird Dell Printer issue

Thanks for the information. The failure to print is on EVERY pdf, not just one, 
so I do not believe it is the file, and they do print fine on all other 
printers. 

No big deal, I will get hold of Dell, but I thought it might be a universal 
issue someone had the answer to on the tips of their fingertips.

Thanks. I did try these remedies with no success. Since we have other printers, 
it is just a bother that I am tired of dealing with.

-Original Message-
From: HELP_PC [mailto:g...@enter.it]
Sent: Thursday, July 01, 2010 8:56 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Another option suggested in a forum

In Printer preferences, select Advanced, press the +-sign at Postscript Options 
and choose Optimize for Speed instead of Encapsulted PostScript

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org]
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of any 
PDF. I don't see any settings that might affect that, and the PDFs print fine 
on other printers. What is different about PDF files that might cause this? 

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

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

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

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

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

RE: Weird Dell Printer issue

2010-07-01 Thread John Aldrich

Steve,
If you ever get the solution, please let me know. I have one Dell laser
printer and it exhibits the same behavior. Fortunately, we have a big
Kyocera MFP just a few feet away in the common area so it's not a huge
deal.. :-)



-Original Message-
From: Steve Kelsay [mailto:kels...@sctax.org] 
Sent: Thursday, July 01, 2010 9:09 AM
To: NT System Admin Issues
Subject: RE: Weird Dell Printer issue

Thanks for the information. The failure to print is on EVERY pdf, not just
one, so I do not believe it is the file, and they do print fine on all other
printers. 

No big deal, I will get hold of Dell, but I thought it might be a universal
issue someone had the answer to on the tips of their fingertips.

Thanks. I did try these remedies with no success. Since we have other
printers, it is just a bother that I am tired of dealing with.

-Original Message-
From: HELP_PC [mailto:g...@enter.it] 
Sent: Thursday, July 01, 2010 8:56 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Another option suggested in a forum

 
In Printer preferences, select Advanced, press the +-sign at Postscript
Options and choose Optimize for Speed instead of Encapsulted PostScript

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org] 
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of
any PDF. I don't see any settings that might affect that, and the PDFs print
fine on other printers. What is different about PDF files that might cause
this? 

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

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


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



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

R: Weird Dell Printer issue

2010-07-01 Thread HELP_PC

Last chance is to print as image 


GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org] 
Inviato: giovedì 1 luglio 2010 15.09
A: NT System Admin Issues
Oggetto: RE: Weird Dell Printer issue

Thanks for the information. The failure to print is on EVERY pdf, not just one, 
so I do not believe it is the file, and they do print fine on all other 
printers. 

No big deal, I will get hold of Dell, but I thought it might be a universal 
issue someone had the answer to on the tips of their fingertips.

Thanks. I did try these remedies with no success. Since we have other printers, 
it is just a bother that I am tired of dealing with.

-Original Message-
From: HELP_PC [mailto:g...@enter.it]
Sent: Thursday, July 01, 2010 8:56 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Another option suggested in a forum

 
In Printer preferences, select Advanced, press the +-sign at Postscript Options 
and choose Optimize for Speed instead of Encapsulted PostScript

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org]
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of any 
PDF. I don't see any settings that might affect that, and the PDFs print fine 
on other printers. What is different about PDF files that might cause this? 

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

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


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

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

Re: Windows 2008 security event ids

2010-07-01 Thread James Rankin

Looks good to me, cheers!

On 1 July 2010 14:05, Tammy  wrote:

> I have found this resorce to be quite useful:
>
>
> http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx
>
> Tammy
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>



-- 
"On two occasions...I have been asked, 'Pray, Mr Babbage, if you put into
the machine wrong figures, will the right answers come out?' I am not able
rightly to apprehend the kind of confusion of ideas that could provoke such
a question."

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

RE: Weird Dell Printer issue

Thanks for the information. The failure to print is on EVERY pdf, not just one, 
so I do not believe it is the file, and they do print fine on all other 
printers. 

No big deal, I will get hold of Dell, but I thought it might be a universal 
issue someone had the answer to on the tips of their fingertips.

Thanks. I did try these remedies with no success. Since we have other printers, 
it is just a bother that I am tired of dealing with.

-Original Message-
From: HELP_PC [mailto:g...@enter.it] 
Sent: Thursday, July 01, 2010 8:56 AM
To: NT System Admin Issues
Subject: R: Weird Dell Printer issue

Another option suggested in a forum

 
In Printer preferences, select Advanced, press the +-sign at Postscript Options 
and choose Optimize for Speed instead of Encapsulted PostScript

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org] 
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of any 
PDF. I don't see any settings that might affect that, and the PDFs print fine 
on other printers. What is different about PDF files that might cause this? 

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

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


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

Re: Windows 2008 security event ids

On Thu, Jul 1, 2010 at 8:50 AM, James Rankin  wrote:
> Anyone have a good resource for looking up Windows 2008 security event ids?

http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/

http://www.eventid.net/

-- Ben

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

Re: Issue with Phantom Pagefile.sys

On Thu, Jul 1, 2010 at 8:28 AM, Ziots, Edward  wrote:
> I see the pagefile on the D:\ drive and after a server reboot I
> see the updated timestamp on the d:\pagefile.sys file but I don’t see it on
> the reminant c:\pagefile.sys, and this was 6GB in size, but a little worried
> about deleting the file accordingly from the system and not having it boot
> accordingly.

  In my experience:

(1) If a page file is configured but does not exist at boot, it will be created.
(2) The page file is locked when in use, so you can't delete an active
page file, so if the system lets you delete c:\pagefile.sys, it is not
active.

> Any idea if there is another place in the registry I can look that might be
> set to keep this pagefile.sys drive on the c:\ drive

  I believe all the page files should be enumerated at:

Key: HKLM\System\CurrentControlSet\Control\SessionManager\MemoryManagement\
Value: PagingFiles

-- Ben

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

re: Windows 2008 security event ids

2010-07-01 Thread Tammy

I have found this resorce to be quite useful:

http://www.ultimatewindowssecurity.com/securitylog/encyclopedia/default.aspx

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

Windows 2008 security event ids

2010-07-01 Thread James Rankin

Hi guys / gals

Anyone have a good resource for looking up Windows 2008 security event ids?
I used to use the old Windows 2000 website from MS which has served me well,
to the extent that I know my 644s and 539s off by heart, but now in 2008
they all appear to have changed, I've got 4740s and 4625s coming out of my
ears as I try and track down some suspicious account activity. Any good
pages out there - I can't find one after a bit of Googling unfortunately...

TIA,


JRR

-- 
"On two occasions...I have been asked, 'Pray, Mr Babbage, if you put into
the machine wrong figures, will the right answers come out?' I am not able
rightly to apprehend the kind of confusion of ideas that could provoke such
a question."

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

R: Weird Dell Printer issue

2010-07-01 Thread HELP_PC

Anothe option suggested in a forum

 
In Printer preferences, select Advanced, press the +-sign at Postscript Options 
and choose Optimize for Speed instead of Encapsulted PostScript

GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org] 
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of any 
PDF. I don't see any settings that might affect that, and the PDFs print fine 
on other printers. What is different about PDF files that might cause this? 

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

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

R: Weird Dell Printer issue

2010-07-01 Thread HELP_PC

A bad character that stops the printing
Print the file to another new PDF file and retry 


GuidoElia
HELPPC

-Messaggio originale-
Da: Steve Kelsay [mailto:kels...@sctax.org] 
Inviato: giovedì 1 luglio 2010 14.35
A: NT System Admin Issues
Oggetto: Weird Dell Printer issue

I have a Dell W5300 ;laser printer that will only print the first page of any 
PDF. I don't see any settings that might affect that, and the PDFs print fine 
on other printers. What is different about PDF files that might cause this? 

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

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

Weird Dell Printer issue