At the risk of insulting some people's intelligence, let me point out that all those group policy settings are needed on every server that the OSD script connects to. As far as I'm aware, whether you do any of that stuff on the core server is actually irrelevant. What matters is that you do it on all the servers that the OSD connects to (i.e. maps a drive to), which may or may not include the core server.
Plus one more throw-away comment: show that list of policy settings (p 49 of the deployment guide) to your average security adviser and chances are they'll tell you no way, forget it. And if the server is in a domain, perhaps you can't even get the required settings because the domain imposes stricter settings. The assumption that an organisation is going to be found willing to relax security sufficiently for a DOS net use to work is increasingly unrealistic.
Good idea, moving to WinPE.
There is a reason we had to add WinPE and LinuxPE. DOS is just not a vaible option anymore.
We have been using this dos imagaing for close to 3 years now, and unfortunalty, at this point, WINPE is not an option.
The Core Server is W2K3 and the SQL VServer is also W2K3.
Going to Jan's comments, would the GP apply to the SQL box, since it is still only mapping back to the core, but yet still talking with the SQL box? Again we have been doing it this way for a long time and then this started last Thursday.
I see where others have had this issue and no resolution. I am still owrking on Paul's ideas as well. I did have the network team remove all GP's from the two servers and made no difference, and I know by just removing the GP that some have to be applied to actually have them removed, but those would not affect what I was testing.
I also and waiting for Joe form the tech team to call and work on some ideas as well, hopefully amongst all this someone can finally come up with a resolution for everyone.
I tried creating a local user with all the correct permissions and share permissions and not luck also.
I also tried creating a new share local on the server with the correct perissions and also did not work.
Just tested the client formt he server vlan as well to eliminate any ports issues and still not working, still saying invalid password to the share.
as Paul said do you try to map the share with net use?
Did you try to change the entry of "corehost" in STARTENV.BAT to IP address in the files dosundi.1 and bootmenu.1?
Did you add the entry in the LMHOSTS files of dosundi.1, bootmenu.1 and ldvboot.img?
Did you add the drivers and did you change the nic.txt in ldvboot.img?
Did this problem happen for every hardware types? (We've had a lot of problems with newer hardware with SATA/NIC/etc. and used Linux boot, before switching to WinPE!) Sometimes newer hardware can't use the undi drivers and need special drivers (but than other hardware won't work :-( )
Since we use PE, we've no big problems with NIC, the performance is much more better as with DOS (download time is reduced immense), we can use DNS aliases, no memory problems with driver loads (SCSI/SATA/NIC) in higher memory (s. himem.sys, emm386, etc)...
Aye - your best troubleshooting is going to be via NET USE here (and my recommendation about breaking out into the DOS command-line) -- because until you can successfully run NET USE, this will not work.
One of the MANY, many arguments against DOS is that your troubleshooting options are EXTREMELY limited (trying to figure out what's going on with NET USE is not much fun, I know - but at least you have command-line and can repeat your tests easily) - WinPE allows for a lot more freedom here.
What exactly are the restrictions against using WinPE? Limited memory of client devices? Something else? It's possible that a roadblock is seen here that may well be not as big a thing as one thought.
Re: SQL Server and GPOI's -- no, the policies do not apply to the SQL server.
The policies apply to EVERY box that is directly involved in the OSD process. This means:
- The Core server itself
- Any additional server(s) who are accessed by shares. (i.e - anything that you try to authenticate to).
This is really your first priority. Also - my personal experiences with DOS networking tend to lean towards staying away from anything that complicates things - including VLAN's. Generally, DOS tends to work easiest in a "no fancy stuff" setup.
- Paul Hoffmann
LANDesk EMEA Technical Lead.
Here is the net use screenshot, connected fine.
No WINPE here until the network systems team tells me we can, not my decision, I have entered the argument.
I have both the smartenv and lmhosts set to IP already. As I said this this all has been working or almost 3 years and then all the sudden last Thursday this happened. I went to the network team to just do a box restore and appearnetly that is not possible at this time as well, so I am stuck with trying to just solve this issue.
I appreciate everyones help and keep it coming. I will check out the SQL box as well and the security policy settings for it.
net use.JPG 53.4 K
That looks like you ran NET USE from a working XP machine and not from DOS. That is not even remotely the same.
Before the mapped drives line add this line:
Then when you PXE boot and run the script, you will get a command prompt that you can type at and you can test NET USE from the actually DOS pxe environment.
As a follow up to everyone working on this with Larry, it looks like there is a problem where the server itself is in a bad state in many ways. This appears to be just one symptom of a much larger problem. This core server will be completely reinstalled.