cluberti

Either you are not the owner of the folders, or the Users or Authenticated Users group does not have access to these folders. I've seen HomeGroup cause this (it changes permissions and ownership of folders and files to allow HomeGroup to work properly), as well as some antivirus applications. I doubt it's malware, as the lock icon simply indicates someone or some group that would normally have access does not, or you do not own those folders (but may still have permissions to access them). Given you can remove it and they come back, I'm guessing it's ownership.

Looks like the site is getting the data server-side in the initial GET request (if I funnel myself through a proxy, it gets the proxy's address, rather than running a script on the local client). Probably server-side PHP before the page is served, given it's an Apache webserver on CentOS Linux reporting itself as PHP 5.2.11.

Use a Server Core machine, and you *do* type logoff to log off .

Then please don't post this in the unattended section - it's for questions about unattended installations. I've moved your post to the scripting/programming section, as that's where you're going to get the most help. Do you have a language preference - for example, powershell vs vbscript?

Right - was it captured once the FULL OS was installed or was the initial install booted into audit mode only? You may have already determined where I'm going with this - a full install disables the admin account and creates a second (admin group) account, and I've never had any real luck with images created this way. Images created from audit mode then sysprep seem to all have worked fine, in my experience.

We've got TONS of posts on this topic on MSFN already - seek and ye shall find.

Yeah, it's not the fact it happened (pretty much everyone who bought Intel boards from Taiwan during that span had bad cap issues), it's what Dell did to cover it up and try to avoid dealing with it. If you called them on it head-on they would do something for you, but only if you were large enough to have purchasing power. And if you DIDN'T call them on it, they just replaced bad boards with other bad boards in the hopes your warranty would expire before they got another call with the same problem.

You need the 32bit patches if you're running a 32bit version of the OS, and 64bit patches if you're running a 64bit OS (even if the application, like Windows Media Player or Internet Explorer, runs in a 32bit version by default). Download the Microsoft patch that matches the underlying architecture of your OS only.

If all you want is scan on demand, your question has indeed been answered. Also, the plural of virus is technically viruses - the double-i plural is only for latin words who's root also ends in i .

If your hard disk is a SATA disk that's attached to a SATA controller not in IDE (or sometimes called legacy) mode, then you'll need to add the requisite SATA chipset drivers to your XP install before it'll see the hard disk.

From the product manual for NG15: There's a Symantec knowledge base article on how to do this in NG15 as well, here.

The problem at that point is perhaps the certificate, or more likely, perhaps the chain of trust to the trusted root that spawned that certificate you're using. Using alternate names for the server (and the name you're using to initially connect, and if you're using TS Gateway or not) can all play into this.

Please be aware of a few things - first, while MSFN is a worldwide site, quite a few visitors to this site are generally not working or online on weekends (the numbers of users online during the week and subsequent drop-offs in those numbers on roughly Saturday and Sunday would indicate this). Second, in the US, Sunday is a national holiday and I am going to be even less from the US will be online during a holiday weekend like this one. To sum it up, have some patience. If you bump a thread after 6 hours on a Saturday morning to most of our users you're just going to appear to be a nuisance, not to mention it's a violation of rule 2.a to bump a post within 24 hours of posting, so I suggest you read the rules again as you've obviously forgotten at least some of them already (and you've been here all of a week). Give it a few days before you bump again if you get no answers.

If you're merging two Win7 DVDs, they're not going to fit on one DVD anyway. Assuming you're doing this for network or USB key installs, you could simply export each installation option you want from each install.wim to one new install.wim, and make a copy of the x86 Win7 DVD. Replace install.wim from the copy x86 Win7 DVD with the new, combined one, and copy that to your network install or USB installation location, and it should work. No need to rename sources and pray when this will work fine with existing processes and tools.

Without auditing already enabled and showing the problem in historical logs, we can only guess. Has this user ever had another username in AD, or was this directory migrated/merged with another AD tree at some point in the past? Those are the only things I could think of that might explain the "old" or wrong SID, otherwise, it's probably just a one-off that you should file away in your documentation in the off chance you ever need it again.

Which version of the RDC client are you using? The old RDC5.x client that shipped with XP/2003 would have issues with certificates if the cert name didn't match, whereas Vista ships with RDC 6.x (and Win7 RDC 7.x). Also, XP and Vista/Win7 have different certificate underpinnings, so upgrading the RDC client on your XP machines to 7.x might not help, but it's worth a shot.

The only problem with this is if the owner of a key is TrustedInstaller, and you lack "write" rights to a key - powershell tries to open the key as writable (to change the owner), which of course will fail. In this scenario, the only way I've found to get the above to work at all is to run powershell with psexec as a user that *does* have write access (this is usually SYSTEM), and then it works. I've resorted to using subinacl/SetAcl for this instead from script.

I know of ways for script to detect the *current* resolution, but getting access to a monitor's optimal resolution (as well as what the video card can actually do) is probably not going to be something you can get at from script. I'm guessing that would require some actual code - I'll look it up, but don't hold your breath. For what it's worth, here's the javascript: <script language ="javascript"> var ScreenWidth = window.screen.width var ScreenHeight = window.screen.height var ScreenColorDepth = window.screen.colorDepth javascript:alert("Screen Width: " + ScreenWidth + "\nScreen Height: " + ScreenHeight + "\nColor Depth: " + ScreenColorDepth); </script> There's always the video change utility we have here on MSFN in the XP unattended area that can SET resolution and display them all (though not both at the same time).

What about the screen output? The log doesn't capture all of it...

Glad to year you've fixed it - I'm not surprised it was Java, honestly. The only more poorly-written add-ons (IMHO) are Adobe's Reader and Flash controls.

For EnableLUA, it may be different on a 2008 server unattend - I only have ready access to 2008 R2 at this point (I could download 2008 media from MSDN, but I'm just too lazy to do so). As to the rest, like I said, it's doable (I've probably done all of the above at least once), but it's going to involve your own script (I use MDT to do a build and run these as TS commands after the OS is up and running when I need to).

Hmmm - honestly not sure unless Samsung has updated the drive FW to specifically score high in Winsat - can you paste the screen output and provide a log file from running winstat disk -v -log <path and filename of logfile>.log? I doubt it's the AMD controller in this case, but...

No, that's up to what the video driver does on first load (Nvidia and AMD video drivers do this, but the later versions of Intel's graphic drivers do not, for instance). You can set a resolution in your unattend.xml, but it's not a guarantee a system will use that resolution, because again, the display size is initially controlled by the display driver itself - it will try to set that resolution, but if it fails, the display driver gets to choose.

Sounds like it's trying to PXE boot after a reboot because it didn't find a bootable OS on a hard drive (or didn't find a hard drive at all). Does your hard drive show up in the list of devices attached to the system when the BIOS goes through it's POST?

Not sure what's happening there - what is the specific drive / model # / serial # and what is the specific motherboard chipset, driver version, and connection type (assuming SATA)?