Aerospace

Thanks for the input, you've been quite helpful.

Thanks for moving to a better location. The company transition overlap makes sense. I don't know why this didn't cross my mind. Follow up question: The current MSP does from what I'm told probably 95% of the work remotely (which I think is part of the issue.) During this transition period they will have to be onsite in order to communicate properly with the replacement company correct? Or in this case since they are rarely there anyway, is there any formal or informal "log" as to what the MSP is actually providing to help the new MSP see what's actually going on?

I'm consulting with a non-profit group about their current server management company. They have had constant issues with them, paying lots of money to fix issues and not getting results, only ambiguous invoices mainly of lots of remotes services. Basically the organization has no idea what's been going on and don't fully trust the current services being provided. The organization does not know the extent of hardware/software or management involvement that this company has on them. The information I have thus far is they are running 1 data server (general file storage), an accounting server (they use Quickbooks for all their accounting so I'm thinking either just another data storage or it's terminal/application server), Exchange server, NAS backup server and one unidentified server. There may be another offsite backup server/service provided by the current server management company (documents I have been given elude to this but do not explicitly state). The organization is currently attempting to get more detailed invoices of services that have been rendered and documentation on all services and details the company is providing for them. All the servers appear to be running Server 2003 R2 flavors, I have not been able to get direct access to the software systems at this time to verify. My question is: How difficult is it to drop a server management company: A. and change to a new company? B. or (if resources allow) to convert to an in-house IT management? (The organization would prefer this option if feasible.) I know there are a number of unknowns here and I will update when I have more info. I am looking for any help whether general, from experience or directions pointing me to the right resources. I've never dealt with completely dropping a management company before so I appreciate any input on what to expect. Not sure if this is the right place to post but it does deal with Windows Server 2003 flavors. I'm not as concerned with red tape or monetary issues. My concern is the network state (hardware and software) and and its management. If there is a better location, Moderators please feel free to move it as you see fit.

I have an update script that I use at work and it also makes an updated list of... updates every time it runs. Basically it generates a list of whatever updates I add to a folder. It's not detailed at all. It's just a list of the actual downloaded update files, but here it is. I should also mention that it contains all updates I have found over the past months and I did not remove any that where superseded by others. This may not be a complete list for all versions of Vista, its primary use is for Home Premium. This is also my list for the x86 Vista. I have a separate list for x64, although I think they are pretty close. Most of my x64 list is the same but with x64 in the place of x86. Hope you or someone finds this useful. CAPICOM-KB931906-v2102.exe msxml4-KB936181-enu.exe msxml4-KB941833-enu.exe msxml4-KB954430-enu.exe NDP1.1sp1-KB929729-X86.exe windows-kb890830-v2.1.exe WindowsUpdateAgent30-x86.exe WindowsXP-KB951072-v2-x86-ENU.exe WindowsXP-KB951376-v2-x86-ENU.exe Windows6.0-KB905866-v22-x86.msu Windows6.0-KB905866-v23-x86.msu Windows6.0-KB905866-v25-x86.msu Windows6.0-KB933729-x86.msu windows6.0-kb937286-x86-en-us.msu Windows6.0-KB938371-v2-x86.msu Windows6.0-KB938464-x86.msu Windows6.0-KB940157-x86.msu Windows6.0-KB941569-x86.msu Windows6.0-KB941649-v2-x86.msu Windows6.0-KB941651-x86.msu Windows6.0-KB941693-x86.msu Windows6.0-KB942288-v2-x86.msu Windows6.0-KB942624-x86.msu Windows6.0-KB943055-x86.msu Windows6.0-KB943078-x86.msu Windows6.0-KB943170-v2-x86.msu Windows6.0-KB943411-x86.msu Windows6.0-KB943509-v4-x86.msu Windows6.0-KB943729-x86.msu Windows6.0-KB943899-v2-x86.msu Windows6.0-KB944325-x86.msu Windows6.0-KB945381-x86.msu Windows6.0-KB945553-x86.msu Windows6.0-KB946026-x86.msu Windows6.0-KB946041-x86.msu Windows6.0-KB946456-x86.msu Windows6.0-KB946665-v2-x86.msu Windows6.0-KB947562-x86.msu Windows6.0-KB948590-x86.msu Windows6.0-KB949189-x86.msu Windows6.0-KB949545-x86.msu Windows6.0-KB949939-x86.msu Windows6.0-KB949961-x86.msu Windows6.0-KB950050-x86.msu Windows6.0-KB950124-x86.msu Windows6.0-KB950125-x86.msu Windows6.0-KB950126-x86.msu Windows6.0-KB950194-x86.msu Windows6.0-KB950478-x86.msu Windows6.0-KB950489-x86.msu Windows6.0-KB950582-x86.msu Windows6.0-KB950636-x86.msu Windows6.0-KB950759-x86.msu Windows6.0-KB950760-x86.msu Windows6.0-KB950762-x86.msu Windows6.0-KB950888-x86.msu Windows6.0-KB950917-v2-x86.msu Windows6.0-KB950974-x86.msu Windows6.0-KB951066-x86.msu Windows6.0-KB951072-v2-x86.msu Windows6.0-KB951072-x86.msu Windows6.0-KB951327-x86.msu Windows6.0-KB951376-x86.msu Windows6.0-KB951618-x86.msu Windows6.0-KB951698-x86.msu Windows6.0-KB951978-x86.msu Windows6.0-KB952287-x86.msu Windows6.0-KB952627-x86.msu Windows6.0-KB952664-v3-x86.msu Windows6.0-KB952709-x86.msu Windows6.0-KB952714-x86.msu Windows6.0-KB953155-x86.msu Windows6.0-KB953395-x86.msu Windows6.0-KB953733-x86.msu Windows6.0-KB953838-x86.msu Windows6.0-KB953839-x86.msu Windows6.0-KB954154-x86.msu Windows6.0-KB954160-x86.msu Windows6.0-KB954211-x86.msu Windows6.0-KB954366-x86.msu Windows6.0-KB954459-x86.msu Windows6.0-KB955020-x86.msu Windows6.0-KB955069-x86.msu Windows6.0-KB955302-x86.msu Windows6.0-KB955519-x86.msu Windows6.0-KB956390-x86.msu Windows6.0-KB956391-x86.msu Windows6.0-KB956841-x86.msu Windows6.0-KB957095-x86.msu Windows6.0-KB957097-x86.msu Windows6.0-KB958644-x86.msu Sorry, my browser was being weird and I didn't see the replies on the original post that already answered the question. Sorry for any duplication.

Thanks guys! You've given me a lot to work with now. I'll play around with these and see what's going to work best for me. @Mr Snrub: The Program Files x86 folder test is so simple, I don't know why I didn't think of it.

Hello, I am working on a manual Vista update script (well batch actually) and I'm looking to find if there is some sort of test as a command line, VB script or something of that nature to determine if the current installation of Vista is x64 or x86. Right now I have 2 separate batch files, one for each type (x64 and x86.) I would like to simplify it to one that could determine on its own which set of updates to use. I've had no luck searching the forum or Google. Does anyone know of any relatively painless way to do that or is what I want going to be a complex project?