Two of my sandboxes upgraded today to Spring 13, and I can't Deploy metadata to them using the Force.com IDE. I'm seeing the errors:

Problem: Unknown type name 'MobileSettings' specified in package.xml

Problem: Unknown type name 'SecuritySettings' specified in package.xml

Has anyone seen this or know of a workaround? IDE is upgraded to latest version (26).

It's definitely a Spring 13 issue, as I was able to Deploy code yesterday before the sandbox upgraded.


  • 1
    Identify the xml part that's causing error .In your metadata file just search for these words and try to remove from xml and save in your local eclipse then try deploying. Jan 12 '13 at 6:55
  • Yep - tried that. Those words don't appear anywhere in the package.xml (or anywhere else in the project).
    – kibitzer
    Jan 12 '13 at 9:06
  • Steps to reproduce (for those who want to try): Create new Eclipse IDE project on Main org (Winter 13) Add to metadata any item – in this test, I added a single custom field on the Lead object. Right click on object and select Force.com – Deploy to Server. Deploy to Spring 13 sandbox. Request overwrite of the field. Click on Validating Deployment. You will see failures: Unknown type name 'MobileSettings' specified in package.xml Unknown type name 'SecuritySettings' specified in package.xml
    – kibitzer
    Jan 12 '13 at 9:08
  • Is your main org not updated to spring 13 ?Since its not updated the problem thats occuring is the package XML is still of API 26 and destination org expects new package.xml Jan 12 '13 at 10:24
  • 1
    As an FYI, this has been reported internally. (Sorry this is entered as an answer instead of a response... it's the whole reputation thing, I guess) Jan 12 '13 at 19:37

Thanks for reporting this issue. I'm the product manager at salesforce.com for this area. This issue will be resolved by Monday evening. It currently affects all deployments from the IDE (regardless if your project includes references to SecuritySettings or MobileSettings).

In the meantime, you can use the Force.com Migration Tool or change sets to deploy to an organization.

UPDATE (1/15/2013): The fix was rolled back last night due to an expected issue. We will try to release the fix again this evening.

  • What's the best way to track if this has been fixed? Should I open a Salesforce Support Case? I just tried a deploy through Eclipse and still getting the errors("problems") mentioned above. Thanks. Jan 15 '13 at 1:10
  • this is pretty annoying...
    – paul
    Jan 15 '13 at 16:25
  • Also seeing this and glad to see it a fix is in works.
    – user2220
    Jan 15 '13 at 18:27
  • Thanks for the update. There should be a place to track this issue. Isn't it supposed to be mentioned in trust.salesforce.com/trust/status ?
    – manubkk
    Jan 16 '13 at 2:43

There have been changes to the metadata API for SecuritySettings and MobileSettings in Spring '13 that are causing the problem for you (see below for more). The issue is that the sandbox is on version 27.0 (Spring '13) and your IDE is still on 26.0 (Winter '13). The version 27.0 IDE will likely not be released until after all of the production instances are upgraded. When it is you can upgrade your IDE and then run your project through the IDE's upgrade wizard.

Check out the Spring '13 release notes, page 112

In Spring ‘13, several Metadata API types have been updated or added to improve support for organization settings. For the declarative file-based API, organization settings types are accessed via the Settings name and setting component member.

For example, the following excerpt from the package manifest file accesses SecuritySettings inforrmation:


SecuritySettings and MobileSettings are no longer available in API versions 25.0 and 26.0.

The following excerpt uses API version 26.0 syntax for SecuritySettings and will fail if used in a retrieve or deploy:


You must remove the SecuritySettings and MobileSettings from your package.xml file or use the new API version 27.0 syntax.

There is a question on how to override the API version in the ide or alternatively you could look at the force.com ant migration tool. If you do anything where you manually edit the package.xml in Eclipse make sure that you uncheck whatever components you need to in the GUI to make sure that the problematic XML doesn't get generated again.

Interestingly, there is an idea to open source the IDE and SF product management mentions that SF is hard at work on the tooling api (btw, awesome!!!), also released in Spring '13, and that it would allow for an open source implementation of an Eclipse plugin.

  • Nice answer peter !+1 Jan 12 '13 at 13:00
  • 3
    I figured it was something like this - but, in terms of developer support, I find it unacceptable for Salesforce to break this critical ability for what could be a significant period of time. I think they should provide a workaround or a patched IDE for the interim.
    – kibitzer
    Jan 12 '13 at 18:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.