Chad

The registration process just creates a web URL with parameters such as mac address and hostname in it, so it shouldn't be too hard to script something. Or you could just hit the DB directly which would probably be my preferred option! Incidently, if you use OCS inventory, I wrote a plugin which will import your hosts directly from it into FOG. The auto-register functionality was removed (so I understand) as laptops connected wirelessly would register their wifi mac as the "primary" mac address, which likely wouldn't be the same mac used when they're imaged.

Also used it for years - more so in browser address bars than office, where I find it the easiest/quickest way to select the entire address line (after falling in the 15 click trap mentioned above and clicking too quickly past the initial click which selects all anyway...

Citrix have released new versions of both XenApp and XenDesktop. Issues fixed in XenApp 6.5: CTX130371 - Issues Fixed in Citrix XenApp 6.5 for Windows Server 2008 R2 - Citrix Knowledge Center Issues fixed in XenDesktop 5.5: CTX130369 - Citrix XenDesktop 5.5 - Issues Fixed in This Release - Citrix Knowledge Center However, it doesn't appear that you can upgrade from a previous version - you need to do a clean install followed by a migration: Installing and Configuring XenApp - Citrix eDocs Chad

Hi FatBoy, You can certainly create a CName (DNS Alias) for the server name to something more meaningful, but users would still have to type http://eclipse:81 Assuming you're using an MS IIS Web server, what you'd also need to do is configure the IIS server to look out for your new preferred name and forward the request to the appropriate hosted site. You can do this with a feature called "host headers". Have a search for that relating to your version of IIS and you should find what you need. Chad

We have .net 1.1, 2.0, 3.0, 3.5 and 4 on our image and I've not had any problems in joining the domain (FOG v0.31) I've recently patched FOG with a mod from the site which modifies the sysprep file immediately after imaging. This populates the correct hostname and the domain join instructions in the sysprep file, which means that the PC has the correct name and joins the domain without the need for the usual additional 2 reboots. As a start, I would try updating the FOG client on your image, as it looks like you're using an old (netdom required) version. Note that the client auto-register was removed about the same time as the dependency on netdom, so be bear this in mind if you need this feature.

I think 2008R2 provides more features (such as ABE enabled DFS) but I was unable to pursue such a setup as our forest functional level is too low at the moment. Hopefully setting the NTFS/share settings can be set centrally too and will propogate through to all replicas - definitely something I'd like to see, but I don't know if that's there either at the moment.

And also: The disadvantage to using a redirected folder is that you can modify it on the fly, and the changes are instant, rather than requiring the users to log off and back on. Scenario: using a DFS based shared desktop, somebody forgot to tie down the security permissions to read only on a new replica added into the DFS. It didn't take long for students to discover that, sometimes after logging in (i.e. when they were directed to that particular DFS replica), they had write access to the desktop. On saving an MP3 there, suddenly it appeared on an awful lot of desktops! Other files then followed with, let's say, some "creative" filenames which soon led to complaints. Luckily we were using push replication from the master share so they didn't do any permanent damage, and the "file owner" tab proved very useful Chad

Hi Modus, try fog/kernel/nameofkernel Don't forget the file names are case sensitive. Cheers, Chad

You can set proxy settings in your /etc/environment file on your Linux server (on Ubuntu anyway), along the lines of: http_proxy="http://username:password@host:port/" https_proxy="http://username:password@host:port/" Which works fine for most proxies. However, if your proxy uses NTLM authentication, rather than a username/password passed explicitly, then you'll need to use something like NTLMAPS to authenticate for you. You then set the host:port in the proxy settings to the IP:Port of the box running NTLMAPS (the port defaults to 5865)

For v0.30 there was a big update to the init.gz, moving to the use of "busybox" which made the PXE downloaded component much smaller (6Mb as opposed to about 30Mb for 0.29). However, many people reported very poor download/imaging performance with this version. One model of PC we use went from imaging in 5 mins to about 40mins with v0.30. Rolling back the init.gz file to that from 0.29 solves the problem, but at the expense of some of the improvements to upload speeds which were also added in 0.30. This doesn't really bother most people though as the download speed is the important factor. My advice would be stick with 0.29 for now if you're happy with how it performs. The interface rewrite in 0.31 is pretty major and there are fixes being reported and posted every day. I think it'll be a little while before it settles down. Chad

It's still very much php for the time being. The new release is a major interface revamp, I'm not sure what additions or improvements have been made. Looking at the FOG forums there's a lot of activity now on tweaking the code and bug fixing in general. I think I'll stick with 0.29 for now and wait and see what the general consensus is - I got very poor performance from 0.30 so would be interested to hear if that's been addressed in 0.31.

The voice of the Daleks too. I was watching the extras on Dr Who/Genesis of the Daleks just the other day and Roy has a few slots of "how to talk Dalek". Being done "live" and without the ring modulation, it sounded just like Zippy

Someone on the FOG forums reported that multicasting was broken with 0.30: Link Rather than reverting to 0.29, you should be able to substitute the init.gz from 0.29 into your /tftpboot/fog/images folder. I use a similar setup after experiencing a number of problems with 0.30, and the speed and other issues I was seeing went away. I don't use multicasting though so can't say for sure if it will fix the problem you're seeing.

btw, FOG doesn't give friendly test for some of the error codes, here's a few return values and what they mean: 5 = "Access is denied" 87 = "The parameter is incorrect" 110 = "The system cannot open the specified object" 1323 = "Unable to update the password" 1326 = "Logon failure: unknown username or bad password" 1355 = "The specified domain either does not exist or could not be contacted" 2224 = "The account already exists" 2691 = "The machine is already joined to the domain" 2692 = "The machine is not currently joined to a domain"

The hostname settings should be copied from the default ones when you tick the "jojn AD" box but I've seen FOG "remember" the old host settings before (they're actually stored against each host in one of the tables). Try blanking all the domain boxes against the host, then unticking thejoin domain, then save. Then if you tick join domain again it should pull through the global settings. I'd leave the username as domain\username (with domain in short name-only format) and make sure magic quotes is off in the php.ini file (restart apache if you make a change, assuming you're on a Linux box - don't know about the windows server setup)

Code 87 is a very unhelpful "The parameter is incorrect". Is your OU field blank? Make sure there are no trailing spaces at the end of any of the AD fields in FOG, I've seen that catch folk out before.

Check that magic_quotes is set to off in your php.ini file for Ubuntu, this file is found at /etc/php/apache2/php.ini Look in the fog.log on the PC and see what errors are reported by the hostnamechanger module. You may need to increase the size of the log file which you can do by tweaking the ini file in (from memory) program files\fog\etc\

For Domain joins, initially leave the OU field blank as there's a bug in the hostnamechanger.dll which causes the domain join to fail IF you specify an OU, AND IF the PC already has an object in AD. I posted a fix for this on the FOG site (the error you get is 2224). If you do eventually specify an OU it needs to be in LDAP format, e.g. OU=Workstations,DC=mydomain,DC=co,DC=uk Otherwise your settings should be hopefully be OK now. Just ensure the user account you are using has sufficient rights to join PCs to the Domain. Good luck!

Do you mean netdom? That's no longer required as from FOG v0.29 - I've never installed it and hostname changes and domain joins work fine. Are you on an old version of FOG? Glad you got it working anyway!

I've never had FOGCrypt fail on me like that! Do you have another PC you can try it on, or do you get the same result there? Have you tried downloading it again, perhaps it's corrupt or didn't extract properly? I think I extracted it from the tar.gz on my PC using 7zip and it was fine.

No problem! The failure you're getting seems to be related to the password as suggested. To initially get things working I left the pass-phrase in the hostnamechanger.dll at the default and encrypted the password for the AD account I used with the FOGCrypt tool. Once you get it working then you can look at securing it up by changing the pass-phrase and recompiling hostnamechanger.dll if you wish. Don't forget that all the clients will need this modified version copied to them too though.

It uses the mac if you do a quick register on the host rather than a full register, in which case it asks what hostname you want the PC to have. Quick registration doesn't require any user input so FOG makes up values based on the values set under "FOG Settings". If you list the hosts from the FOG server web interface you'll see what it thinks they should be called, and you can rename them there to whatever naming scheme you really want. Next reboot, the PCs will check in with FOG and they'll see they have a new name assigned and change themselves to match. You can also change the default naming convention should you prefer to use quick registration from FOG settings. Rather than MAC based you can make it, e.g. PC-xxxx where xxxx is an auto incrementing number. Cheers, Chad

It was more an idea to try to see if WDS's PXE wasn't playing nice and servicing the whole LAN regardless of DHCP options. On the Citrix one I had issues with, turning off the Citrix PXE service resolved it. Clients set with DHCP 66 and 67 pointing to Citrix still network boot from it as expected, and those pointing to FOG boot to FOG. Sorry I can't be more specific, I only tried WDS for a brief period and wiped that server long ago.

Your logic is sound, and the reservation method should work for the few clients that you want to boot to WDS as it does for the few booting to FOG. I'd look in the running services on the WDS server for a "PXE services" one and try disabling it temporarily and see if that helps. Like most MS stuff, it likely assumes that you want their servers to perform all roles by default. Chad

It's been a while since I looked at WDS, but I had a very similar problem recently when setting up a Citrix Farm which may give you a pointer. Check that the WDS server isn't providing PXE services - it just needs TFTP to provide the boot files. FOG needs to do all the PXE stuff and just point the clients to the relevant server. In my case the Citrix server was over-riding FOG and PXE booting the clients on the same VLAN, it may be something similar for you?