morganw

Or you can type su, then when prompted enter the root password, then run the installer.

Thats proxy -colon- proxyport e.g. myproxy:8080. Not a smiley face.

Have you defintely got internet access to download the packages and if you made the VM behind a proxy you'll have to check the that you have the correct repositories as the installer doesn't like the lack of internet access. To let apt access the internet I normally give the proxy settings directly by making a file called /etc/apt/apt.conf which contains: Acquire { Retries "0"; HTTP { Proxy "http://proxy:proxyport"; }; };

The transfer won't know about how the computer was syspreped so it shouldn't make a difference, I've only ever used sysprep -mini -reseal -quiet. Have you tried switching to a different kernel or a different model of PC and then seen if the problem persists?

I'm running FOG, on Debian Lenny, on XenServer and i've had no issues so far. I downloaded the Debian install disc from here: Debian Lenny » XenServer - Citrix Community

If what you are doing now is based on deploying a sysprep image then you can put more drivers and some HAL switching into it to reduce the number of images you have. Moving to Fog would give you mostly the same as what you've got now, and as far as I know deploying XP via MDT & WDS is still based on sysprep and has the same limitations. I've got about 25 differerent types of PC and got this down to 2 images after using the tools and information available from www.vernalex.com If you are moving to Windows 7 then changing to MDT & WDS seems the easiest way to go unless you are using value added features in FOG or Ghost, in which case, you'd probably end up using the new sysprep.

If you need to go through a proxy for internet access the interface will run slowly unless you've given the proxy details on the settings page.

I would say all of the files listed here: FOGUserGuide - FOGProject Wiki If you wanted to test I guess you could try not using the client updater, just stop the service on a workstation, manually replace the files in C:\Program Files\Fog, then restart the service.

You can use the 'FOG Client Service Updater'. Press the 'i' on the web interface, and then choose 'Client Updater'. I haven't used it yet as I've only just started using the service, but I presume you just upload the new service components and the clients will download them and use them on the next service start.

This should work, just put into notepad and rename to .adm CATEGORY "Logon Settings" KEYNAME "SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" POLICY "RasDisable" VALUENAME "RasDisable" VALUEON "1" VALUEOFF "0" END POLICY END CATEGORY ...but test it first - I haven't used it in a while.

Can you get a BIOS update for this? I would guess it's more likely to be a problem with the PXE implementation or a issue timing of the machine startup. Check the BIOS for settings like "wait for hard disk" or any other startup timing parameters, some computers will have this incase the drives spin up too slowly. You could try changing the drive to a different model which, if it works, would suggest a timing issue with the drive. You could also try using another NIC or using Etherboot to try a different PXE implementation.

Are you using Open Directory or Active Directory to provide directory services? Is the Mac server joined to the domain? Could you use an Samba share on the Mac server or are you moving to use AFP? It would be easier to just use another Windows server unless you are moving for some kind of functional change.

Depending on the applications you use would it be worth considering using the money for a terminal server + licenses rather than increasing the memory? If you use them as RDP terminals with something like thinstation you'll get better performance and have increased scope for good remote access as part of the deal. It would save on Windows 7 licensing as well if you aren't on an MS schools agreement.

If you aren't familar with robocopy there is a lot of good documentation for all of the switches Robocopy You might want to to increase the values on /R and /W to something like higher like /R:3 /W:30 for a backup in case you get a temporary network or power fault during the backup.

It looks like the computer names come directly from the folder names that are found in G:\Eureka\MyDocBack. The 'For' part is basically saying for each directory in the current folder (G:\Eureka\MyDocBack) - do this. %%f represents the folder name, which gets passed into the robocopy options as a computer name. The rest looks hard coded for the computer called kpryor and viper so that isn't going to do anything different regardless of how the folders change. To add a new computer to back up I would just make a folder for it. i.e. G:\Eureka\MyDocBack\Harri1010

You put the config file in the same directory as the MSI and then it installs with the settings you want, finds your server, and then takes additional settings / config changes from it. I've never had to push anything and i've had no problems although I've only been using this since the summer. Whenever I've spoken to support they are usually pretty switched on and talked me through most things.

...and what is this one? C:\ProgramData\Microsoft\Windows\Start Menu Too many for my liking.

Thanks. Which policy stops the merge?

I've got a Terminal Services / XenApp server which is working okay but I can't work out how the start menu is built. Anyone that logs in gets the start menu from the their mandatory TS profile merged with the one located here: C:\ProgramData\Microsoft\Windows\Admin Start Menu\ This is the first I've looked at profiles outside of XP so I'm unsure how this works. Logic would suggest that the Admin Start Menu would only merge onto the start menu of an administrator, not every user. Could anyone clarify this for me?

There is also a bug (maybe just in the latest version) that means you cannot set the AD parameters on a per group basis, if you do it will drop the the backslash from the string. Normally if you can't joing the domain the username is in the wrong format or the account doesn't have permission to add computer objects to the OU or container.

You shouldn't have to restart as it isn't load balancing as such, it's just the maximum number of unicast downloads that can occur at once. I found that in certain parts of the building 6 was the most effcient, in other parts 2 or 3 was faster overall - depends on your infrastructure.

Well it didn't arrive in time to setup in the summer. I've had it since the start of September but i've also had a massive problem with virtualisation infrastructure so I haven't done anything but try and resolve this. It looks like it needs to activate online, so it'll probably need it's own image. I'm still on the lookout for other alternatives but in terms of features this is still the only one that meets all of our requirements (if it works). In the long term I think we may look at using Apple commputers, unless there are massive changes to the way the audio system is managed in Windows 7, Windows doesn't seem useful in a multi-user environment for audio work - mainly due the inconsistencies in levels and routing you can achieve across workstations with little effort. No money to make this change at the moment, but if we had any I'd make the change right now.

Is it possible to look at the backups at a filesystem level and recover a file without having to restore the entire server to something, then boot it, then get the file?

If anyone has any experience troubleshooting FC connections with Emulex HBA cards I've got a XenServer 5.6 system that runs everything and can't stay working for more than a day. From the kernel log: Sep 17 17:52:25 xenserver02 kernel: lpfc 0000:15:00.1: 1:0459 Adapter heartbeat failure, taking this port offline. Sep 17 17:52:28 xenserver02 kernel: lpfc 0000:15:00.0: 0:0459 Adapter heartbeat failure, taking this port offline. Basically the storage disconnects, this happens on both physical servers and we've elimanted all other hardware, looking like a driver issue or a firmware issue on the HBAs. On the off chance that someone reading this knows a lot about Emulex HBAs running on Linux, I'd appreciate any help or suggestions. Thanks.

If you can reduce the wait by increasing bandwidth it wouldn't appear to be the same issue that I had. Are you sure that you haven't changed anything else at the same time as upgrading your connection speeds? You could try disabling the computer browser service, but if you have services which depend on netbios lookups working (e.g. CC3 build process) then that will cause problems. I would think the behaviour you now have is correct, more surprised that it would ask for credentials on Server 2003. A better bet would be looking at 'Access Based Enumeration' for the shares or as a last resort just put a $ on the share names to make them hidden. If you've got an Samba shares you can make them hidden without the $ by changing the config.