MDT and SCCM Webservice Issues

Dec 21, 2011 at 4:26 PM

Hi everyone, I have been trying to implement the Deployment webservice in our environment and ran across a couple of issues that maybe someone can help with. 

The first issue pertains to the MDT functionality. After installing & configuring the webservice all of the MDT test calls fail to return anything. I assumed this was due to the stored procedures so we went ahead and tried to add them to our MDT DB. When we executed the code it returned this error:

Msg 208, Level 16, State 1, Procedure RoleMappings, Line 6 Invalid object name 'dbo.RoleIdentity'.

Does anyone have any ideas on what the cause of this could be?

The second issue is with SCCM and most likely due to a security rights issue. Similar to the MDT issue none of the calls return any information. We are using a service account created just for our deployment process. The security rights for the AD portion work perfectly but we are missing rights for the SCCM portion. I guess my question would be what set of permissions are required for this account in SCCM. Obviously we want to provide it with the least rights as possible. Any suggestions would be greatly appreciated.

Apr 24, 2012 at 1:33 PM

I'm getting the same error.  Anyone able to figure out a solution yet?

Apr 24, 2012 at 1:36 PM

I found the solution out here:

http://www.sqlteam.com/forums/topic.asp?TOPIC_ID=109708

Turns out in the DB selection drop down I had the "master" DB selected.  When I selected the correct DB for my MDT server it worked like a charm.  Hope this helps.

Coordinator
Apr 24, 2012 at 1:40 PM

The requirement of Stored Procedures is hopefully obsolete soon. With the Beta of the new version of the MDT Web FrontEnd released, the web service will soon be updated to use the same libraries to access the database. And with this it will be able to get rid of the Stored procedures. 

Anyway. Looking at the error message I would assume, that you executed the sql script against a non MDT Database. RoleIdentity is a default table from MDT, so it should always be available. Most often, if you open the sql script in the SQL Management Studio, it points to the wrong database (e.g. master). There is a Database selector (typically top left in the "SQL Editor" Toolbar). Make sure you have the correct Database selected. 

If the script went through and you still have problems accessing them, it's most likely a permission problem. Just be aware, that db_reader and db_writer don't give enough permission to execute Stored procedures on default. For testing I would recommend giving db_owner permission.

Regards

Maik

Coordinator
Apr 24, 2012 at 1:52 PM

lol, seems we had some overlap with our answers ;-)

But glad you found the solution yourself.

Apr 24, 2012 at 2:25 PM
Thanks for the fast response!

How will that new MDT Webservice work? I just upgraded to MDT 2012 yesterday and haven't gotten a chance to explore all the new stuff.

As you saw I did get that portion working, but now I get a 404 page not found when I got to: http://localhost/mdtwebservice/mdt.asmx

Any help you could give would be greatly appreciated!

Thanks,
Marshal

On Tue, Apr 24, 2012 at 7:40 AM, MaikKoster <notifications@codeplex.com> wrote:

From: MaikKoster

The requirement of Stored Procedures is hopefully obsolete soon. With the Beta of the new version of the MDT Web FrontEnd released, the web service will soon be updated to use the same libraries to access the database. And with this it will be able to get rid of the Stored procedures.

Anyway. Looking at the error message I would assume, that you executed the sql script against a non MDT Database. RoleIdentity is a default table from MDT, so it should always be available. Most often, if you open the sql script in the SQL Management Studio, it points to the wrong database (e.g. master). There is a Database selector (typically top left in the "SQL Editor" Toolbar). Make sure you have the correct Database selected.

If the script went through and you still have problems accessing them, it's most likely a permission problem. Just be aware, that db_reader and db_writer don't give enough permission to execute Stored procedures on default. For testing I would recommend giving db_owner permission.

Regards

Maik

Read the full discussion online.

To add a post to this discussion, reply to this email (mdtcustomizations@discussions.codeplex.com)

To start a new discussion for this project, email mdtcustomizations@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com