cluberti

That would be my suggestion - machine startup script, or loosen permissions right down to that specific location on the box and live with the reduced security. Apps that require users to write to protected areas of a machine should be thrown out as soon as possible anyway, or at least the developers drawn and quartered in public, and then replaced with competent ones that care about security.

If you could post the BSOD, and if there was any .dmp file generated, post that as well. Otherwise, we're all guessing. That won't get us very far, if history is any teacher.

If you find out what it is, let us know. As far as we're aware, files and links from this site are clean of malware, although we cannot guarantee that sites linked by users in posts on this site are all safe.

Yes, but a group change requires a logoff to take effect. This isn't easy to script, either. The real question is, why does the user need to make a change to a file in Program Files? Can this be done via a script run from another management tool that runs as admin?

mswish@microsoft.com still seems to exist. That was the "old way".

Would the users have access to credentials that they could input to elevate the script if prompted? Otherwise, you're making the users admins or removing restrictive permissions on the program files folders; those are your options.

If you mean can I share Office 2003, no. However, if you're just talking about some VBA code, or a COM dll add-in, etc, then yes, you can share your own code.

#1 - Actually, Outlook 2007 and 2010 use autodiscover (protocol) to look up the autodiscovery information for a user (what you're doing by trying to discover the user/mailbox server) published by Exchange 2007 and 2010. It will find your name and/or email because it exists as an exchange-enabled account in AD, but it won't find your mailbox server. This is because if your Exchange servers are 2003, it can't/won't find any autodiscover options, and this will fail with that exact error (MAPI_E_INVALID_PARAMETER) because no autodiscover service exists in the domain - the failure is actually the call to the (nonexistent) autodiscover service point. #2 - Add the admin templates from Microsoft to your domain to get policies for Office 2010.

They don't. Whomever provided you the DVD should be reported to Microsoft and the BSA. If you grabbed it off the 'net, you should know better.

You find out if you pass around the time the exams come out of beta, and if so, you get full certification on your transcript. @Trip, I've found that simple knowledge of how things work is enough to pass most of the deployment exams, so even if you're not doing what's on technet, knowledge of it (and what you've learned from experience) is enough to get by (especially considering beta exams have tons of questions, unlike a normal non-beta exam). I say do it if it's going to be something that aligns with your job, because there's no downside other than time out of your day studying technet and taking an exam for a few hours.

Not always, but in this case, likely. You might want to see if you have any *other* .net updates for the runtime in question that are newer than any of these, as not all .net updates like installing when newer updates are already installed (see 974417 as an example). Sometimes removing all of the updates that are failing, and any new ones, and then reinstalling in KB-chronological order will fix things. Not saying that's what is happening here, but it seems at least a possibility.

Then it looks like your need for Nero means you'll be buying a new copy if you get a Windows 7 machine, 32 or 64bit. Consider that part of the cost of your upgrade when doing your pricing/budgeting.

Yes, if it has a fan, remove the current one and replace it with another.

Except for those of us who do NOT want all new networks to be considered public. Given that I know the name of the window (and the fact it'll be on the domain when it's used for the first time, where the issue occurs), I just wrote a little app to kill the window and run as part of my task sequence (as when that window occurs on a domain network, the network's already been set). Works quite well, actually, but of course as with your method, it has it's drawbacks. I did it with simple AutoIt script that I run in my Task Sequence, for anyone interested. Yes, it is that simple: $handle = WinGetHandle("Set Network Location", "") WinClose($handle)

In your unattend you will need to modify the Microsoft-Windows-Shell-Setup section in Specialize to have it's <Themes> section point to %windir%\Resources\classic.theme.

Honestly, Windows Firewall + Microsoft Security Essentials has been enough for almost everyone I've installed it for - the only time it wasn't, we were infecting the machine on purpose (and even then it wasn't easy to do! ).

An HTA can run vbscript, jscript, or HTML (it's just an HTML container inside a WebBrowser Control). If you can write a page that loads a .net activex control, you could probably run it in an HTA.

My wife, singing happy birthday to me, poorly (on purpose). Quite amusing, actually - nice way to start the day.

This almost sounds like it could be achieved with an HTA in RunOnce or something much quicker/easier than writing a whole app for it .

Depends on the internet server, cloud provider, etc. I still don't understand the question, or this is maybe just too vague. From what I understand, you have a 2003 server on a private network, and you need to upload a visual foxpro database to an internet-accessible machine. If I'm understanding this correctly, either you have to contact a provider and follow their instructions, or find a way to allow access to your server through the router/firewall in front of it.

That would depend on what you use the machine for. I would recommend, if you *really* want a general idea of how much memory (actual, committed virtual address pages) your system is using, this can be done in perfmon as a Data Collector Set (for gathering data over time) - again, it's going to be an estimate, but it's a very good, close estimate to what your usage patterns will require in physical RAM (or RAM + paging file, so you can determine if you need a paging file or not).In perfmon as a User Defined Data Collector Set (start > run > perfmon > Data Collector Sets > User Defined > Action > New > Data Collector Set > Advanced > Performance Counter), you can add the "Working Set" counter under the "Process" object, and select the "_Total" instance. Then, add the "Cache Bytes", "Pool Nonpaged Bytes", Pool Paged Bytes, and "Available Bytes" counters under the "Memory" object. These give you: Working Set - Gives you the amount of memory pages that have been used recently by running processes, and as such are almost all going to have been mapped into physical RAM. This number will be larger than the actual total process memory utilization due to shared pages between processes being counted multiple times as a process working set. Cache Bytes - This number gives you a real-time display of the value of the system cache, the system driver resident bytes, the system code resident bytes, and the kernel paged pool bytes that are cached in RAM. Pool Nonpaged Bytes - This counter gives you the amount of the kernel nonpaged pool resource size - this pool is ALWAYS mapped into RAM (thus nonpaged pool, and cannot be paged out to a paging file). Pool Paged Bytes - This counter gives you the amount of the kernel paged pool resource size - this pool contains memory data that can be written to disk (in the paging file) if necessary, but is usually stored in RAM until the memory manager determines it needs physical RAM pages (when the system RAM gets full/busy/etc). Available Bytes - This gives you the amount of physical RAM available for system use, and is equal to the total amount of memory assigned to the standby (cached), free, and zero page lists (I won't explain them here, it's too deep for this discussion - Windows Internals is good for a deep dive on these if you really want to learn more). Now, spend a few hours doing the things you'd normally do, and then go back into perfmon and stop/review your Data Collector log. Specifically, add up the averages and high-water marks for these 5 counters (they're all in bytes, keep that in mind - not MB or GB, but bytes), and you have an approximation of the actual virtual address footprint of your machine. To a very close approximation, you'll know how much virtual address pages your system uses, and in general, to where the pages are going. If this number is always less than the amount of physical RAM (in bytes) installed on your machine, you don't need a paging file (unless you run apps that explicitly don't run without one, and those are rare). If the number is ever close (and you'll have to determine what level of "close" you want to abide, if this is the case), you're going to want at least a smaller paging file, and if your usage patterns show numbers that are always way over the amount of physical RAM with your perfmon results, obviously, you need a paging file.

You might also want to consider something like FreeNAS or OpenFiler - both are very good products, both are open-source, and both are free as in beer. If all you're going to do is serve files over SMB, either will work, and something like FreeNAS is lighter on the hardware. It also gives you other features/options like iSCSI, which I prefer (mounting iSCSI drives on my Win7 workstations) over using SMB shares and network drives.

I believe the action center settings are just reg values, although off the top of my head I don't remember which anymore. However, this is expected - all security-related settings like the Security Center get reset after sysprep, even with copyprofile=true. You should be able to replace the reg entries with a startup script in RunOnce for that user, though, and put things back "the way they were" so to speak.

The keys don't match because one is the Dell pre-activated key that is validated by the BIOS after install, so them not matching is expected. At this point, the system is good to go and you can return it to your friend as-is. As to the avatar, I found it years ago and I honestly don't remember where at this point.

It's likely that the CD is pre-activated using the BIOS (since it's a Dell BIOS that matches one the CD recognizes, it's pre-activated).