Forum Replies Created
-
AuthorPosts
-
Well at least I know it is the GPO. I built a WDM server with the same SQL DB build, same WDM version, and the same Microsoft patches. The only difference is I placed the computer account in an OU without GPOs applied to it. The ActiveX errors are gone so now it is just a matter of finding the offending GPO setting that is screwing this up.
November 3, 2009 at 6:42 pm in reply to: DHCP options required for PXE booting XPe wyse terminals #16877@ConfGen wrote:
In the first step you do NOT need any DHCP option tags. WDM and its DHCP Proxy will take care of this.
186 is very useful for letting the units know where the WDM server is located. But this is only working with latest XPe WDM agents of 4.7.1 version.Don’t configure 66 at all.
CG
I have a follow-up question to this. If there is more than one PXE-capable solution in an Enterprise environment, would the DHCP Option Tag 186 be preferable than multiple IP Helper statements?
Yes I do have an Enterprise License. The issue hasn’t occured before in over a year of using the product. The folder was deleted, but when I recreated the folder or try to add a new package, I get the same ActiveX errors.
I tried making a fresh server and the same issues occur, so the only things I know that are the same is the following:
1) The Microsoft patches applied to the server.
2) The GPO that is applied to the server.
3) The SQL server build that the database is installed on.
4) The version of WDM that is installed.I am going to try and eliminate the top two reasons for I believe it is there where the problem is.
I am still experiencing these errors and am at a loss as to why they are occuring.
Anyone seen this type of error before?
The server is a member server. I went and tried modifying the permissions on the Inetpub directory giving the Rapport account modify rights and giving the IUSR account read/execute.
Are we sure that VM 3.5 is a platform that can be used to install WDM on a W2K3 Virtual Server?
When I try the website, it gives a 401 error.
The SQL server account made by the installer was not changed and I verified I could log into the console using the rapport account with the ThinMgmt_451 password as noted in the Installation Guide.
My apologies for not getting back sooner, but I was out on a deployment to a remote site.
I ran DebugView and FileMon on the box. I also went through the event logs. Even though there is no change and am using an assigned password that meets password requirements, there is a Logon error in the application log for the rapport account on SQL going through the named pipe connection.
Also, in DebugView, there is a No Ack Received message for the server on port 8008 as well as the HServer port or address is null message.
In FileMon, the RptStdSvc.exe has a dll error with not finding the DBmsLPCn.dll file on the box.
ON the SQL Server, no server records are present for port 80 in the Server table.
I have an image with the VM to roll it back prior to installing WDM. Any ideas?
When the client and the WDM server was on the same VLAN, there was no difference in the issue.
The build with the DB on the same server as the WDM is a different VM box. Both servers that I have built have been on VMWare and have images that I can reload at any time.
I have been continuing with my troubleshooting efforts and am stumped. One common symptom is occuring that I have found that has me baffled.
Regardless if I have the RAPPORTDB on a separate SQL box or on the same box that WDM is on, the record in the Server table for port 80 is not being created.
I have tried reinstalling the RptStdSvc, I have tried having the server in an OU without any GPOs, and I even tried manually adding the record. Nothing so far has allowed me to get discovery to work properly. DHCP is working fine and the device is not even getting the proxyDHCP error anymore. However, discovery does not work and I can’t push any packages to a device if I manually add it.
The servers are Windows 2003 with SP2 installed with a basic IIS configuration with FTP and WWW installed. SQL is the 2005 version. DEP is set for only essential services.
Would moving the WDM box to the same VLAN as the DHCP server help?
It appears that DHCP was actually up and running on one of the over servers in the lab, except it was configured to look at a different VLAN for client machines. I moved the thin clients to that VLAN and the devices are no longer getting DHCP errors on PXE boot.
However, I am still unable to image or even discover the devices on VDM. Right now, the WDM server, the DHCP server, and the client devices are all on separate VLANs.
I still get the “proxyDHCP offers were received. No DHCP offers were received” error.
Also, I didn’t load DHCP separately. I was under the assumption that WDM also had it’s own DHCP service built in.
DEP was not set properly so I fixed that and I had the Rapport account already set to never expire. When I restarted the server, I no longer got any error messages in the WDM Services Logs. However, no improvement has occured in discovery or DHCP functionality.
One last thing. On the DHCP log in the WDM Service Logs, I am getting an error of “Either HServer address or port is null – cannot respond to RTI device”.
-
AuthorPosts