morganw

I think unless you are using some kind of WebDav service to achieve something you generally won't notice the difference.

Hi, My problems disappeared if I disabled the webclient services on the clients. Are you still on XP or are you on Windows 7 now?

I went to test it today and it doesn't print, it just says printing but nothing comes out. I'm sure this worked before, and it will print a test page from the server. Sorry for the false hope, these printers are a waste of time and money.

We've got two of these, one of which is working on a Windows 2008 32bit print server. I'm about to add the second. My colleague downloaded the driver so i'm not sure where he got it, I assume just whatever is the latest XP driver on the support site. One of these was for use with Apple Macs and I can't locate the driver to operate this through the windows print queue, but I can work it by connecting directly to the printer via Bonjour or HP IP printing whereby it seems to conjure a driver from nowhere. I can probably email you the Windows driver i'm using as I think it's left on the desktop at the moment.

Is the image set to single partition NTFS resizable, and are you sure that the computer you are imaging doesn't have a hidden restore partition or something like that? Try booting a Windows CD are creating a single partition, then reboot and deploy the image onto that.

I would go for Fog if are using Windows XP, it's currently missing some functionality for Windows 7 though so if you want to run that I would look more towards WDS. I'll vouch for Fog as never having let me down, just re-imaged about 600 PCs with no issues. I found it faster for unicast deployment than WDS as well.

My script is here. If deploying through group policy then I would put it as a batch file in a startup script using some kind of receipt or file check to see if it's already installed. Something like: if exist C:\Program Files\SIMS\something-that-exists-post-install goto skip install script goes here :skip

As far as I know it just pings with the address from DNS. If it's red without an exclamation mark then it's in DNS but the ping failed. If the firewall is up on the client you have to allow the ping through (I think have to set a couple of ICMP exceptions). If the static address makes a difference is that also changing the way that your DNS records are updated?

Restart the service while watching c:\fog.log to see what happens. A complete cycle for all services will take 6 minutes (I think) so you have to keep refreshing or use a script to tail it. You didn't say that you had restarted the PC, when you install the service it won't be running, either restart the PC or start it using the service manager to make it do something.

Is the error ratio the same on different hardware? Myself and my colleague imaged about 530 PCs with Fog over the last couple of weeks, we only had two that appeared to be corrupted / wouldn't boot and that was with a maximum limit of 6 computers at once. I would class our switch infrastructure as cheap and sub par. Try setting the storage node to only image one PC at a time and then see what happens.

It would be easier to: set up the new server with a new address, install Fog from scratch, transfer your images and snapins (just use something simple to transfer across the network then match the permissions with the old fog server), transfer your database (use sqldump on old server, then import on the new server), reset the passwords (this is the wooly bit that most people need help with as there are a few passwords scattered in various config files), Then switch the IP addresses of the two servers and see if it works, the clients shouldn't know the difference. If you are using DNS entries then you'd have to switch the DNS entries. I've done this before, and along the way have broken pretty much every part of it but normally a mixture of common sense, checking the fog forum, and comparing the old server to the new one will get the job done.

You can download something from the Netgear site called 'Smartwizard Discovery' which will scan for switches and check that the IP addresses are valid. If you have power cuts you'll need this to identify which switches have reset and come back without a valid IP address.

All of my snapins are just .cmd files that are uploaded to the fog server - this way you can install MSI files via msiexec, use a silent install switch, import registry fragments etc. if you wanted to import a registry fragment the easiest way is make a read-only deployment share on a server, then make a .cmd file that contains regedit /s "\\server\deploymentshare$\fragment.reg" Then upload that .cmd file as the snapin, you wont have to set any run with options or anything like that, just give it a name, upload the file and then save.

Did you have to change any SATA drive controller settings in the BIOS in order to install Windows XP?

I would get a spare PC and set that up set as a fileserver, then try pointing to that for the redirection. If that works then you know it's something to do with the configuration of the original server, if it doesn't work then it's probably something wrong with something global like group policy settings. It might help to narrow it down.

I did an upgrade last weekend and found that the database would get upgraded but some post-processes would hang. In the end I think I had to loosen the permissions on the /tmp folder so the upgrade procedure would go all the way through. Not sure where the designated temp folder would be on a Windows installation though.

...and, you have to delegated the management of computer objects to the fog AD account so that computers can join, you could always test with the domain administrator account and password just to see if that is the problem.

On the 'Fog Settings' page I've entered FOG_AD_DEFAULT_DOMAINNAME: school.internal FOG_AD_DEFAULT_OU: -I leave this blank- FOG_AD_DEFAULT_USER: school\FogADUserAccount FOG_AD_DEFAULT_PASSWORD: -here you paste in the output from the fog password encryptor- Now when registering the client either check the box in the user interface next to 'Join Domain after image task', the other boxes will populate with the default values, or the same thing will happen if you register the computer through the PXE boot menu, just answer 'y' at the appropriate point. I thought the active directory join was broken on my system but in actual fact I had just forgotten to check the box in the user interface. For debugging check the output of the log file in C:\fog.log.

When you extracted the new moodle folder you'll have to change the config.php file to include your old site address, mysql username and mysql password. You'll get that error if you haven't changed it.

Hmmm. i'm running out of ideas. Do your DHCP and DNS run inside the domain or are they external? You could also try disabling SMB v2.0 on your server as XP won't use it anyway, not entirely sure how to do it though - you have to go do it in the registry. XP will negotiate down to the older SMB protocol so mayeb this is somehow going wrong. You could set up another fileserver and see if you get the same delay, or try a Vista/W7 client and see if you get the same delay.

Do you also get the same delay when you login (time between pressing enter and the logon screen disappearing)? What kind of profile are you using, if it's mandatory or roaming try letting a local profile build instead. If the permissions are wrong on a mandatory profile then I think that would cause a delay while navigating folders as the folder redirection changes will try to write back to the profile, although again I think that is for a longer delay than 2 to 3 seconds.

Is the delay once per logon session, or if you typed it again do you get the delay again?

389 is LDAP, the internet tells me that 53 is DNS. If you checked the name lookup of the domain controllers and fileserver (probably use nslookup servername) then that would suggest it's a delay in the LDAP query. That was what I had when I had a duplicate IP address although that gradually got worse through the day and ended up with delays of minutes not seconds. If you access the share directly by typing \\server\home\j.smith into the run box do you get any delays?

To check the redirection value on the server side you can look at a group policy settings report on the GPO that does your redirection. That's pretty much guaranteed to be correct and should have "%HOMESHARE%%HOMEPATH%" as the direction value. To check that it isn't doing anything bizare you would need to be on a client, then just echo the variables from within a command window. So for a network account, you should get: echo %HOMESHARE% --> "\\SERVER\Sharename$" (assuming you use one share per user) echo %HOMEPATH% --> "\" so the redirection points to "\\SERVER\Sharename$\" I think that what is happening is that you have something which makes a delay while resolving this path, similar to mine caused by the WebClient service. I don't think that a mapped drive would be affected as the address of mapping would only be resolved once as the drive was actually mapped, from then on the system is only resolving drive letters so there would be no delay. If you did want to try disabling the WebClient service you can do this through the service management of Group Policy Preferences so you wouldn't have to physically go to every PC.

Yes, if you do it that way then the My Documents redirection should be based on %HOMESHARE%%HOMEPATH%. If you log in and type echo %HOMESHARE% and then echo %HOMEPATH%, if you join those two together that should show what the system trys to resolve when using the redirection. You shoulnd't have to map the homedrive, i'm not sure whether you meant you map it or you were talking about map drives to other shares, but whatever is set in AD on the 'profile' tab should get mapped automatically and that is where the %HOMESHARE% value should be read from. That is my understanding anyway.