Troubles with GetRoles part of MDT.asmx

Apr 21, 2010 at 1:36 PM

Hey, thanks for putting this together. Greatly appreciated.

I am having issues in invoking the GetRoles of the MDT.asmx. Basically it does not return the roles from within MDT.

I've tried to setup the MDTDBUser and MDTDBPassword with both SA and Domain accounts, but nothing is ever returned when i run the invoke from the MDT.asmx.

I have another webservice setup that i was testing from the Pretty Cool Front end, and that one is working fine.  but i cannot seem to see what is missing from the web.config to make the connection to the MDT DB.

Any suggestions?


Apr 21, 2010 at 2:01 PM

You are most probably missing the Stored Procedures from the MDT Database. The MDT part of the webservice is currently using a bunch of stored procedures to get and manipulate data. I'm rewriting this at the moment so that this is no longer necessary, but haven't finished it yet. So for now you would need to add the necessary stored procedures to your MDT database. Find the complete download on this CodePlex page at Open the sql file in SQL Management Studio (Express), execute the complete script or feel free to just copy the SPs you want to use.

The webservice also contains an option to enable some tracing that should give you a better idea on what might be failing. See for details.




Apr 21, 2010 at 3:50 PM

OK, thanks, one step closer. Really appreciate this.

Now i do see the Roles, but the AD.asmx appears to ge my next issue, i think.

I am unable to see any of the OS Images, or collections with advertisments, when the HTA fires up.

If i run http://localhost/MDTWebFrontEnd/SCCM.asmx?op=GetOSDCollections it returns the OSD collections as it should.

But I have a number of SCCM sites in one domain, serving different functions based on the business needs. Anyways, the server that is performing the imaging, where MDT/SCCM is hosted and the webservice running from, does not actually manage any clients, it only images systems. I have not enabled publishing to AD for this site.

So when i run http://localhost/MDTWebFrontEnd/AD.asmx?op=GetSCCMAssignedSite it always gives me the site code of the one of the other SCCM servers, that does not have any OSD TS advertisements. i think this is why the OS Image section of the HTA is blank.

Is there a way to set the correct AssignedSite so that it will return the OSD collections with advertisements?

Apr 21, 2010 at 4:12 PM

Yes, check the Frontend.wsf file at line 99. There you should find a comment that explains how to switch this to a call that is using the SLP to query for this. So you actually just have to comment out line 99 and uncomment line 102 ;-)

Apr 21, 2010 at 4:32 PM

Haha, excellent. Thanks Maik. if i have more issues i'll post back, thanks again for your prompt response!


Oct 25, 2010 at 11:37 AM


I'm experiencing a bit similar problems with MDT.asmx. I'm recieving data from both SCCM and AD, but for some reason not from MDT. I installed the Stored Procedures described above and enabled the logging option from the NLog.config, but I'm not recieving anything usefull to the debug, trace or Info logs (Searched for any line with MDT).

If I test the functionality for http://localhost/DeploymentWS/mdt.asmx/GetMakeModels I'm only getting a page like below. Same thing happens with GetRoles, GetModels, GetLocations, etc. I also noticed that during the computer installation (using PrettyGoodFrontendClone) the POST functionality doesn't work either. It seems that the webservice can't query the SQL DB for some reason. SQL Server is not located on the same server as SCCM, MDT or the Deployment Web Service but that shouldn't be a problem, right? I can see from the SQL log that the UserID defined in the Webservice is logging in to the SQL server.

Any suggestions how to proceed?

Result when running http://localhost/DeploymentWS/mdt.asmx/GetMakeModels:

<?xml version="1.0" encoding="utf-8" ?>
<ArrayOfMakeModelIdentity xmlns:xsi="" xmlns:xsd="" xmlns="" />

Nov 19, 2010 at 11:31 AM

Currently the MDT portion of the webservice doesn't deliver much logging. This will be fixed in the next version. It is also making use of a whole lot of stored procedures but as you said you have added them already to the database. Most often it's a problem related to permission. Make sure you can log on remotely to the database with the credentials you have configured for the webservice. Also be aware that the permission to execute Stored Procedure is not part of the e.g. db_datawriter role. So you need to explicitly give permissions to the Stored procedures or simply add a new role to the SQL Server that has the appropriate permission and add the account to that role. For testing purposes I would even make it db_owner to ensure that nothing else is creating issues and then tightening the security later after I've verified that it is working.

Again, in the next version the stored procedures will go away and with it the security problems with them.